Linaria零运行时模式需显式启用并严格约束静态表达式，否则仍会退化为runtime注入；Webpack需配置linaria/loader规则，Vite需启用linaria/vite插件并禁用dev热更新，动态值将导致样式回退至JS注入。
直接切换到 Linaria 并不能自动解决运行时性能瓶颈——它必须配合 zero-runtime 模式启用、静态表达式约束和构建链路校验，否则仍会退化为 runtime 注入。
Linaria 的 zero-runtime 模式必须显式启用
Linaria 默认仍保留轻量 runtime（用于 fallback 和 dev 时热更新），不配置就等于没切。关键不是“用了 Linaria”，而是是否真正关掉了 JS 样式注入逻辑。
- Webpack 用户需在
linaria/loader配置中加{ sourceMap: false, displayName: false, rules: [{ action: 'ignore' }] }，并确保未引入@linaria/react - Vite 用户必须使用
linaria/vite插件，并在vite.config.ts中明确设置dev: false（生产模式）且禁用hot相关逻辑 - 检查最终 bundle：如果仍有
insertRule、createTextNode或style.textContent =调用，说明 zero-runtime 未生效
动态值写法会强制回退到 runtime
Linaria 在构建期做静态分析，任何无法在编译时求值的表达式都会导致该样式块被跳过或 fallback 到 JS 注入——这是最隐蔽的性能陷阱。
- ❌ 错误示例：
color: props.theme === 'dark' ? '#000' : '#fff'（props是 runtime 变量） - ✅ 正确做法：用
defineTheme+ 多份 CSS 文件分离主题，或把条件提前收口为常量：const darkMode = process.env.NODE_ENV === 'production' && THEME === 'dark' - ⚠️ 注意：
import(`./${name}.css`)、Math.random()、new Date()等任意含副作用或非确定性调用，都会让整条样式链失效
生成的 CSS 必须被构建工具正确提取和加载
Linaria 生成的是 .css 文件，但若 Webpack/Vite 没把它纳入输出或未正确 link，浏览器就根本不会加载这些样式——结果是页面无样式，或 fallback 到 runtime 补救。
- Webpack：确认已配
MiniCssExtractPlugin，且linaria/loader在css-loader之前，避免被 css-loader 处理成模块对象 - Vite：检查
build.cssCodeSplit是否为true，并确认public/下无残留的linaria-*.css手动拷贝（会绕过 hash 和缓存控制） - 验证方式：打开产物目录，搜
.css文件；再查 HTML 的，确认有对应，而非内联
如何确认 runtime 真的消失了
别只看 bundle size 降了没——很多零 runtime 库仍会在 dev 时注入 style 标签，混淆判断。
- 在 Chrome DevTools Performance 面板录制一次完整交互，过滤关键词
insertRule、appendChild、style.sheet.insertRule，应几乎无命中 - 在
styled-components的injectStyles或@emotion/sheet的insert方法上打 debugger，确保断点永不触发 - 对比组件 mount 前后：用
performance.mark('mount-start')/mark('mount-end')包住，观察 Flame Chart 中是否还有 “Style” 或 “Layout” 子任务在 commit 阶段高频出现
最容易被忽略的是：Linaria 的静态分析对 TypeScript 类型不敏感，as const 或 readonly 修饰并不能让一个 runtime 变量变成 compile-time 常量——它只认字面量、顶层 const 声明、以及 Babel 可安全求值的纯表达式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
