标准行为与实现行为存在差距
别名: 引擎差异 · 规范与实现 · WebKit · Chromium
概念解释
Web 上同时存在两层「正确」：一份公开标准写明元素、CSS 和 API 应当怎样，以及 Chromium、WebKit、Gecko 各自实际怎样做。日期选择器、对话框、滚动链、剪贴板、全屏、弹性盒的最小尺寸，常常在标准里有定义，在引擎里却是三种控件、三种默认、三种漏洞。按标准画线框图、只在一种引擎里验收，得到的是「在我的浏览器里成立」的产品，不是在用户浏览器里成立的产品。
差距不是暂时的缺陷清单。引擎实现节奏不同，移动 WebKit 还会长期保留与桌面引擎不同的行为。等「大家都实现了」再设计，等于把发布日期交给最慢的那条引擎。
机制
标准是协商出来的文本，实现是带历史包袱的代码。同一段标准允许「未指定」的细节，引擎就会用自己的控件外观、自己的焦点顺序、自己的性能取舍去填。前缀时代结束后，特性以无前缀名字上船，名字相同不再保证行为相同——position: sticky、<input type="date">、dialog、overflow 滚动是否把滚轮传给父级，都是名字对齐、语义分叉。移动端还多一条：系统浏览器内核往往落后于或锁死在某一代 WebKit，桌面 Chrome 上调通的 API 在手机里根本不存在。
因此「标准支持」不能从 Can I Use 的绿点直接翻译成「可以依赖」。绿点只说明有这么一个 API，不说明控件外观、键盘行为、无障碍树和错误态是否能用。设计若把未对齐的细节当成平台惯例（例如假定日期选择器都带取消按钮），就是在把某一引擎的实现误认成 Web 本身。
边界
只面向单一引擎的内嵌 WebView（企业壳、某些小程序内核）可以把该引擎的实现当作事实，差距缩小到壳升级周期。打印样式、电子书和邮件客户端是另一类残缺实现，不能用浏览器引擎的差距模型去套。已经冻结、各引擎高度一致的子集（基本文档流、链接、表单 GET/POST）差距很小，不必为它们做引擎分支。自动化测试若只跑一种引擎，测不到这条差距——绿的测试套件和用户投诉可以同时成立。
怎么落地
- 把关键交互写成「标准意图 + 各引擎实测」两列：日期、对话框、滚动、剪贴板、文件选择、全屏，在 Chromium、WebKit、Gecko 上各走一遍，记下控件外观和失败态，而不是只看支持表。
- 对仍分叉的行为，不要在视觉上假装有统一控件；用应用自己的界面包一层，或接受系统控件在不同引擎里长得不同。
- 移动 WebView 与桌面浏览器分开验收，不把桌面调通当作移动已通。
- 验证：用三种引擎打开同一条关键路径，列出行为不一致的步骤。任何一步只在一种引擎里可完成、或控件缺少取消/关闭，都是把实现当成了标准。把这份清单纳入发布门槛，而不是当作「已知问题」挂着上线。