固定高度写进输入框就失效：控件盒模型不是只由样式表决定
一、同一段样式，三种失效
有人做过一件很普通的事：把输入框统一写成固定高度，目的是让表单在页面上对齐。结果在三个内核上看到三种不同的失效方式。某一类内核依赖盒模型计算方式与内边距来解析这个高度，声明被内边距吃掉了；另一类内核忽略这条声明，按内容自己撑高；下拉选择框在某内核下根本不响应高度声明；多行文本框则忽视行高声明。同一段样式，四种表现，没有一种是”渲染错了”，它们各自都按自己的规则在执行。
这件事对交付的启发不在于怎么写这条样式，而在于它推翻了一个默认假设：作者样式表并不是盒子尺寸的唯一决定者。表单控件这一块区域里，浏览器自带的默认样式一直在参与计算，而我们平时看不见它，因为它不报错、不出现在样式面板的”作者样式”一栏里，只在结果上悄悄起作用。
于是组件库里那句”我已经对齐了”就有了两种含义：在开发机上对齐了，或者在承诺支持的引擎集合上都对齐了。这两种含义之间的差是真实的工作量，如果不显式写进报价和验收标准，它就会以返工的形式回来——通常发生在集成测试阶段，改的又是已经复用了这个控件的几十个页面。
二、控件盒模型不由作者样式完全决定
原因可以归结为一句话：各内核的用户代理样式表对可替换元素与表单控件的实现逻辑不同。用户代理样式表是浏览器为了”作者什么都没写时页面仍然可用”而准备的默认规则，它先于作者样式参与计算。普通元素上这层参与很容易消除——不依赖继承来的外观就行；表单控件不是这样，它的盒子本身带有实现侧的处理逻辑，属于可替换与半可替换那一类，盒模型不完全由作者样式决定。
第二个容易忽略的点是默认值集合的差异。不同内核带来的不仅是规则不同，还有默认内边距、默认行高、默认边框与字体度量这一组初始值不同。在这些初始值不一致的前提下，同一条高度声明相当于作用在三个不同的起点上，计算结果自然分叉。把问题归因成”某个内核有 bug”是最省事的解释，也是最没用的解释，因为它不给出任何可执行的处置。
从业者要接受的事实是：这部分控制权不在样式表里。可控的做法不是把声明写得更强硬，而是减少需要由控件自身内部逻辑裁决的量——把尺寸约束交给一个完全由作者样式决定的容器，让控件在一个已经定好的盒子里去处理它自己的内部排版。
三、声明被吃掉的三种机制
三种机制对应三种表现，分开看才不会在排错时用同一套手段反复试。
| 机制 | 现场表现 | 应对方向 |
|---|---|---|
| 内边距与内容撑高参与计算 | 写了固定高度，实际渲染高度随内边距与内容变化，声明像被吃掉 | 显式声明盒模型计算方式，把内边距与行高一并写成确定值，不把尺寸交给控件自己算 |
| 属性对该控件不适用 | 声明完全无效，控件按自身逻辑出高，如下拉选择框不响应高度、多行文本框忽视行高 | 不把约束写在控件上，改由包裹层控高；多行控件的高度交给它自己的行数语义 |
| 盒模型计算方式差异 | 同一声明在不同引擎下分别表现为含内边距或不含内边距，边框与留白把可用空间吃掉 | 在组件层统一盒模型计算方式并显式写出，避免依赖默认值的差别 |
这里最关键的一条是三者的耦合：盒模型计算方式、行高、内边距要一起显式声明，不能只写其中一个。只固定高度而不锁内边距，剩下的空间由谁裁决取决于引擎；只锁内边距而放任行高，文字基线会带着控件内部盒子的实际高度一起漂移。显式三元组的意义是把可变量降到最少，让不同内核面对的是同一组输入。
四、把尺寸约束外移，以及两个特例
可靠做法是把高度约束从控件本身移到包裹层。写法上的分工是：包裹层负责控高，用固定高度或最小高度加溢出策略；控件自身用百分比去填满这个盒子，不再声明绝对高度；行高与内边距显式写出；盒模型计算方式在组件层统一。这样做的好处是，需要被裁决的部分从”控件的内部实现”变成了”普通容器的盒模型”，而后者的跨引擎行为要稳定得多。
外移有边界，不能当成万能。包裹层控高之后，控件内部仍然可能出现文字被裁切或垂直居中位置不同；滚动条、清除按钮等由实现侧附加的元素仍会占位；控件填满容器时，光标与选中区域的位置也不会完全一致。所以这套写法解决的是”高度不再各算各的”，不是”三个内核看起来一模一样”。验收目标要按前者定，后者只能靠视觉规格逐项约束。
两个特例要单独处理。下拉选择框不响应高度声明的那一类情况，只能把外观约束放在包裹层，同时接受展开列表由实现侧绘制，选中态样式与展开层不在同一套规则里；写规格时要把它单独列成一行，不能和普通输入框合并成同一条验收项。多行文本框忽视行高声明，意味着无法用行高去反推高度，合理的路径是按行数与可用宽度定义它的高，并明确它允许随内容增长到什么程度、超出后是滚动还是继续撑开。这两条都是组件文档里必须显式承认的差异，而不是靠一句”按设计稿实现”糊过去。
至于”全部换成自绘组件”这条路，它确实能消除这层不确定性，但不是免费结论。代价至少包括：键盘操作与焦点顺序要自己实现并验证，输入法与移动端原生输入体验需要重新对齐，表单提交语义与校验行为要自建，读屏软件能拿到的信息要额外补齐，长期维护成本转移回团队。合理的取舍是按场景分：一致性要求高、交互简单的展示型控件可以自绘；承载输入语义的控件优先保留原生并做外移处理，这个分界要写进组件库的选型说明，而不是每次评审重新吵一遍。
五、跨引擎验收矩阵：只在调试面板里看过不算
这类差异必须靠实测矩阵来收口，而矩阵的字段要事先定义，否则测出来的只是”我打开过几个浏览器”。矩阵由四个维度构成，交付时按维度记录覆盖，不写结论性形容词。
| 维度 | 要固定的取值 | 每个交叉点记录什么 |
|---|---|---|
| 引擎集合 | 产品承诺支持的引擎，逐条列名，不写”主流内核” | 控件类型、声明是否生效、与规格的偏差 |
| 视口集合 | 手机、平板、桌面各自代表档位，含横竖屏 | 同一控件在不同宽度下的高度与留白 |
| 控件状态集合 | 默认、聚焦、禁用、错误、只读、有值与占位 | 状态切换时尺寸是否跳动，占位与实值是否等高 |
| 深色与缩放档位 | 深浅两套配色，字体缩放与页面缩放各取档位 | 文字是否溢出边框、点击区是否随之缩小 |
“只在调试面板里看过”为什么不算？因为调试面板改的是渲染输出的一部分条件，它不改变用户代理样式表参与计算这一事实，也不覆盖真实输入法、真实滚动条与系统字体度量的组合。矩阵里每一格要留下的是可核对的物件：截图或录屏、当时的声明组合、观察到的偏差，而不是一个通过标记。缺格要显式写成未覆盖，这比填上”应该没问题”有用得多。
六、差异声明与顺带要看的可用性项
组件库交付时，我们随件附三条声明，缺一条就等于把责任留给使用方去发现。第一条是已实测矩阵，写清测了哪些引擎、哪些视口、哪些状态与档位；第二条是未覆盖项，列出没测的组合和遇到时的处置建议；第三条是已知差异与规避方式，把上面两个特例这类无法消除的行为写成条目，给出替代写法。这三条不是免责文本，而是让使用方能在预算内决定要不要接受某个偏差的信息基础。
顺带要在同一轮里看掉的还有三项可用性内容：点击区尺寸是否随控件高度被压缩，字体放大时文字与图标是否溢出边框，键盘焦点在包裹层控高的方案里是否仍然清晰可见。这三项和问题同源——都是实现侧默认值参与计算的结果——但它们的后果比视觉偏差严重，出问题时受影响的是具体的人。
洹拓把这类差异放在报价与验收里显式出现，而不是留给返工：前端工作量中”跨引擎一致性验证”是一项独立工序，它按矩阵格数计，不按页面数计。控件盒模型不完全归作者样式表决定，这是浏览器实现层的事实，不接受也不会改变它；把它写进矩阵和声明，才是工程师对它的正确处置方式。