现代CSS可能让你的前端更复杂
内容提要
现代CSS新特性（如容器查询、:has()）虽能减少代码，却可能让整体系统更复杂。作者通过四个场景说明：新旧实现并存导致行为冲突；container-type会意外改变布局；:has()和嵌套选择器权重过高；性能开销需实测。建议迁移前明确所有权、检查作用域与层叠、删除旧代码并测量性能。
延伸解读
局部简洁不等于系统简单
文章用“合租公寓”比喻：新CSS特性像新租客，虽安静整洁，但会与JavaScript、布局、层叠和渲染引擎共享空间。代码差异只反映局部简洁，即单个文件所需代码量；系统复杂度则是安全修改前必须理解的交互数量。迁移时若只关注删了多少行，容易忽略新旧实现并存带来的行为冲突，最终让调试跨越多个层面。
container-type 的隐藏布局副作用
声明 container-type: inline-size 不仅启用容器查询，还会创建块级格式化上下文并施加尺寸包含。这会阻止外边距折叠、让浮动元素推开卡片，甚至使依赖内容宽度的卡片塌缩为0px。文章建议在添加前确认元素宽度来源：若来自内容，应改为从上下文获取宽度，或将 container-type 移到已有明确宽度的包装元素上，并在真实布局中测试。
:has() 与嵌套的选择器权重陷阱
:has() 本身不增加权重，但其参数会计入特异性，导致 .card:has(img) p 轻易压过组件自身规则。嵌套中的 & 也会借用选择器列表中的最高权重，可能让无关的 ID 选择器影响普通链接样式。文章建议用子代组合器约束匹配范围，并用 :where() 将重选择器权重归零。同时注意，半层叠的代码库中，未分层规则默认优先于分层规则，层叠层并不能自动救场。
性能开销必须实测而非假设
文章用5000行列表测试显示，单独一个锚定 body 的 :has() 规则开销可接受，但与另一条看似无害的 :has() 规则共存时，每次切换会重样式化5001个元素，耗时约7ms；行数增至20000时约31ms。作者强调这仅来自一次Chrome测试，应关注模式而非具体数字。迁移前后应在DevTools中记录性能，比较样式重算、布局和绘制时间，并用生产规模数据验证。
Q&A
为什么说现代CSS可能让前端更复杂？
现代CSS特性（如容器查询、:has()）虽然能减少局部代码量，但可能增加系统复杂度，因为新特性会与现有JavaScript、布局、层叠和渲染引擎产生交互，导致难以推理的行为冲突。
容器查询的 container-type 属性会意外改变布局吗？
会。container-type: inline-size 会创建块级格式化上下文，导致内部浮动被包含、外部浮动被排除、外边距折叠被抑制，并且内联尺寸包含会使内容尺寸的卡片塌缩为0。
:has() 选择器为什么容易导致样式冲突？
:has() 的参数会增加选择器权重，且可能匹配到非预期的后代元素（如评论中的头像），导致样式覆盖其他组件规则。建议用子代组合器约束范围，或用 :where() 降低权重。
迁移到现代CSS时如何避免新旧实现并存的问题？
迁移时必须彻底删除旧实现，包括JavaScript观察器、相关类名和所有引用这些类名的选择器，确保行为只有一个所有者（CSS或JavaScript）。
CSS :has() 选择器有性能问题吗？如何测量？
有潜在性能开销，尤其是锚定在大子树或与其它规则组合时。应使用Chrome DevTools的Performance面板记录交互，比较Recalculate Style、Layout和Paint时间，并启用CSS选择器统计，用生产规模数据测试。
采用现代CSS特性前应该检查哪些事项？
应回答六个问题：所有权（是否只有一个所有者）、作用域（对格式化上下文的影响）、层叠（哪些规则可能覆盖或被覆盖）、迁移（是否删除旧实现并测试所有状态）、性能（是否实测前后负载）、可维护性（后续开发者能否理解规则存在的原因和影响范围）。
