内联 css 主动放弃工程化控制权，导致:hover、@media等失效，维护成本远超初期效率；仅邮件html、critical css和特定动态场景合理使用。
内联 CSS 不是“写得快就值得用”，而是主动放弃工程化控制权——绝大多数项目里，它带来的维护成本远超初期省下的几秒编码时间。
内联样式为什么会让:hover、@media、:nth-child 失效
浏览器对 style 属性的处理是“硬覆盖”：一旦元素带了 style="color: red"，所有外部 CSS 规则（包括 .card:hover { color: blue } 或 @media (max-width: 768px) { .card { width: 100% } }）都必须靠 !important 才能竞争，而 !important 本身又破坏层叠逻辑，导致调试时 computed styles 里全是 inline，根本看不出哪条规则本该生效。
常见错误现象：
- 鼠标悬停没反应，检查发现元素上写着
style="color: #333"，而 hover 规则被静默忽略 - 小屏下布局错乱，因为
style="width: 300px"强制锁死了尺寸，媒体查询无法介入 - 用开发者工具选中元素，
Styles面板里看不到任何 class 对应的规则，只有element.style一栏孤零零写着几行
class 切换比反复改 style 属性快得多
DOM 操作开销不在“写不写样式”，而在“怎么触发重排重绘”。直接赋值 el.style.left = x + 'px' 每次都触发同步布局计算；而切换 el.className = 'moving' 只需字符串比对，V8 和渲染引擎对此有成熟优化。
实操建议：
- 把动态尺寸/位置逻辑封装成 class，例如
.tooltip--shifted { transform: translateX(12px); }，再用 JS 控制 class 存在与否 - 需要响应滚动或 resize？用
requestAnimationFrame批量读取getBoundingClientRect()，再统一设 class，别在 scroll 回调里反复写style.top - 颜色、透明度等可动画属性，优先用 CSS 自定义属性：
el.style.setProperty('--opacity', val)，后续可配transition: --opacity 0.2s
服务端渲染或邮件模板是少数合理使用场景
内联样式不是绝对禁止，而是必须有明确技术动因而非“图方便”。真实可用的例外极少：
- 邮件 HTML：Outlook 等客户端几乎不支持
<style></style>块，必须把color、font-size等逐个塞进style属性 - Critical CSS：首屏关键样式（如 header 背景、标题字体）可内嵌在
<style></style>中，但这是“内嵌”，不是“内联”，且必须严格限于首屏可见范围 - JS 动态控制单个元素不可预测状态：比如拖拽中实时更新
element.style.width，此时用 class 会因重排延迟产生卡顿
注意：style={{}}（React）或 :style=""（Vue）本质仍是运行时拼接字符串，无法提取、压缩、缓存，且 SSR 时环境差异可能导致首屏样式不一致——这类写法和手写 style="..." 一样危险，只是语法更隐蔽。
真正卡住团队协作的，从来不是 CSS 写法难，而是 style 属性散落在 20 个组件、5 个 CMS 富文本字段、3 个后台导出模板里，改一个间距要 grep 全项目，删一行怕影响未知页面。分离不是教条，是让样式变更可预期、可追溯、可批量操作的最低成本方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
