是的，gecko（firefox）和blink（chrome）的box-sizing默认值均为content-box，但firefox对search/number等input类型会隐式应用border-box，而chrome坚持全局content-box，需统一显式声明input、select、button等元素的box-sizing: border-box以确保一致。
不同渲染引擎对盒模型的解析基本一致，但差异集中在默认样式、怪异模式触发条件和表单元素行为上——不是引擎本身不守标准，而是它们对“未明确声明”的处理策略不同。
Gecko（Firefox）和Blink（Chrome）的box-sizing默认值是否一致
是的，box-sizing 默认都是 content-box。但关键区别在于：Firefox 对某些 HTML 元素（如 input、textarea）在特定类型下会**隐式应用 border-box**，比如 type="search" 或 type="number"；而 Chrome 通常坚持全局 content-box，除非你显式覆盖。
- 验证方式：在 DevTools 的 Computed 面板里查
box-sizing值，别只看 Styles 面板写的 CSS - 影响场景：当用固定
width: 200px布局多个表单控件时，Firefox 下search输入框可能比text更“紧凑”，Chrome 下则全部撑开 - 解决办法：统一加
input, select, button { box-sizing: border-box; }，不要依赖浏览器默认
怪异模式（Quirks Mode）在 Gecko 和 Blink 中的触发逻辑差异
两者都遵循 W3C 规范定义的触发规则，但对“不合法 doctype”的容忍度不同。Blink 更严格：哪怕 前有一个 UTF-8 BOM 字节，它就进怪异模式；Gecko 则相对宽松，部分旧版本甚至能忽略 BOM 继续走标准模式。
- 常见误判点：
document.compatMode在 Firefox 控制台返回"CSS1Compat"≠ 真的标准模式——还要检查页面是否被服务器注入了 XML 声明或注释 - 排查命令：
console.log(document.compatMode, document.characterSet)，如果characterSet是UTF-8 with BOM，大概率已中招 - VS Code 中右下角编码显示为
UTF-8（无 “with BOM”）才安全；保存前务必勾选 “Save with Encoding” → “UTF-8”
Flex 容器内子项的 min-width 计算在 Gecko/Blink 中为何不一致
这不是盒模型问题，而是 flex 布局算法实现细节分歧。Blink（Chrome）对 min-width: auto（初始值）的解析更激进，常把图片、内联块级元素的固有尺寸当作硬性约束；Gecko（Firefox）则倾向收缩到内容最小宽度，尤其在容器设了 flex-wrap: wrap 时。
- 典型症状：同一段代码中，Chrome 下图片撑破 flex 容器换行，Firefox 下却正常压缩
- 可靠修复：
img, input, textarea { min-width: 0; }—— 强制放弃固有最小宽度，让 flex 算法可缩放 - 慎用
min-width: fit-content：它在 Firefox 78+ 支持良好，但 Chrome 90–105 存在计算偏差，建议仅用于现代部署环境
最易被忽略的是：盒模型差异往往不是来自 box-sizing 本身，而是来自浏览器对 display 类型的隐式修正（比如把 dialog 当 block 还是 flow-root），以及对表单控件的 UA 样式补丁。真要跨引擎对齐，得先冻结 UA 样式，再重置盒模型，而不是只调一个属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
