内联样式维护困难因其需全局搜索替换、无法复用、不支持预处理器、调试难定位；link优于@import因并行加载、支持媒体查询；css modules等通过哈希类名解决作用域冲突。
内联样式为什么会让维护变困难
直接在 HTML 标签里写 style="color: red; margin: 0"，改一次要搜全项目所有 style 属性，还容易漏掉重复逻辑。比如按钮颜色统一改深蓝，你得翻遍所有 button、a、div.btn 的内联样式，稍不注意就漏掉一个。
更麻烦的是：这类样式无法被 CSS 预处理器（如 Sass）处理，不能用变量、嵌套或 mixin，也进不了构建流程做压缩或 autoprefixer。
- 搜索替换易出错，尤其当值带单位或空格（如
"padding: 10px 0"和"padding:10px 0"不会被同一正则匹配） - 无法复用，相同视觉规则在多个地方硬编码，违背 DRY 原则
- 调试时 Chrome DevTools 里显示为
element.style，和真实 CSS 文件无关联，跳转不到源码
link 标签引入 vs @import 的实际差异
<link rel="stylesheet" href="base.css"> 是推荐方式；@import 写在 CSS 文件里（如 @import "reset.css";）会阻塞渲染，且不支持媒体查询条件提前加载。
关键区别不在“能不能用”，而在“什么时候下载、是否并行、能否被缓存策略控制”：
立即学习“前端免费学习笔记（深入）”；
-
<link>支持media属性（如media="(prefers-color-scheme: dark)"），浏览器可跳过不匹配的资源下载 -
@import总是同步加载，即使写在文件末尾，也会让整个父 CSS 文件等待它完成才解析 - 构建工具（如 Webpack/Vite）通常只识别
<link>或 JS 中的import './style.css'，对@import可能忽略或处理不一致
如何用 CSS Modules 或 scoped style 控制作用域边界
全局类名冲突是维护噩梦的源头之一。Vue 的 <style scoped>、React 的 CSS Modules（import styles from './Button.module.css'）、或 PostCSS 的 postcss-modules 插件，本质都是把类名自动哈希化，比如 .button 编译成 Button_button__kx9f2。
这不是“避免命名”，而是让命名自由——你不需要绞尽脑汁想 header-v2-main-title 这种长名，只要语义清晰即可：
.title {
font-size: 1.5rem;
color: var(--text-primary);
}
编译后它不会污染其他 .title，也不怕第三方库覆盖。
- 注意：CSS Modules 默认不继承全局变量，需显式
:export或通过postcss-import引入设计令牌 - 动态 class 拼接（如
className={`${styles.button} ${isPrimary ? styles.primary : ''}`）要小心空格和 undefined 导致的 class 名错误 - 服务端渲染（SSR）时，若未正确提取 CSS，可能出现 FOUC 或样式丢失
单一入口 + BEM 命名能否替代 CSS-in-JS
可以，而且更轻量。核心不是“用不用 JS 控制样式”，而是“有没有明确的规则约束样式来源和作用范围”。一个 index.css 入口，配合 BEM（.card__header--large）、有意义的文件拆分（layout.css、form.css、theme-dark.css），配合构建时自动添加前缀和压缩，已足够支撑中大型项目。
真正增加维护成本的，从来不是“没用 styled-components”，而是：
– 类名随意缩写（.btn-sml 谁记得是 small 还是 smile？）
– 同一组件样式散落在三个文件里（HTML 里内联一点，JSX 里插一点，CSS 里再写一点）
– 没有设计系统文档，改个主色要 grep 全局找 #007bff
所以集中管理的关键，是让所有样式变更都收敛到一处：要么是那个 variables.css，要么是那个 tokens.json，而不是靠人记住“按钮大小在 button.css 第 42 行，但圆角在 ui.css 第 187 行”。
