直接在CSS文件中@import node_modules路径会失败，因为浏览器原生不支持解析node_modules，且Vite/Webpack/esbuild等打包器默认不处理跨node_modules的CSS @import；必须通过JS/TS入口import触发loader链路解析。
为什么直接在 CSS 文件里 @import node_modules 路径会失败
浏览器原生不支持解析 node_modules，现代打包器（Vite/webpack/esbuild）默认也不处理跨 node_modules 的 CSS @import。哪怕你写了 @import "node_modules/element-plus/dist/index.css";，构建时大概率静默忽略或 404。
真正起作用的路径必须由 JS/TS 入口触发，让打包器走 loader 链路（如 css-loader 或 Vite 内置 CSS 解析）。
-
package.json中的style字段对构建流程完全无效——它只被 CDN（如 unpkg）用于 fallback，Webpack/Vite/Rollup 全都不读 - 真正生效的是
exports字段，比如："./style.css": "./dist/style.css"，否则import 'xxx/style.css'就是 404 - 务必用
ls node_modules/xxx/dist/实际验证 CSS 文件是否存在，别只信文档写的路径
导出组件库 CSS 的正确方式：必须在 JS 入口显式 import
你的组件库不能指望用户自己去 @import，而要在 JS 入口文件中主动引入 CSS，确保它被构建流程捕获。
- 在组件库的
src/index.ts（或index.js）顶部加一行：import "element-plus/dist/index.css"; - 如果用了图标字体等额外资源，也要一并
import "@/lib/iconfont/index.js";（注意路径要能被 alias 解析） - Vite 用户可开启
server.hmr.overlay = true，让模块解析失败直接弹窗，避免黑盒排查 - 不要把 CSS 导入写在组件内部的
<style></style>块里——那只是局部样式，不会随组件导出传播
让用户引入时如何避免样式污染和加载顺序问题
CSS 是全局作用域，重置类（如 normalize、reset）或 UI 框架样式一旦顺序错位，就会被覆盖或失效。
立即学习“前端免费学习笔记（深入）”；
- 把 reset/normalize 导入放在所有自定义样式之前，例如在用户项目的
main.ts最顶部：import "your-lib/style.css"; - 若用户项目用 SCSS/Less，且你导出的是源码而非编译后 CSS，需确认其 loader 支持
~别名，否则@import "~your-lib/src/styles/main.scss";会失败 - 强重置包（如 ericmeyer-reset）慎用于已有项目；推荐渐进式方案（如 modern-normalize）或用
:where()隔离作用域 - 检查用户项目
package.json的sideEffects字段：若设为false，CSS 会被摇树剔除，必须显式放行："sideEffects": ["*.css", "*.scss"]
发布前必须验证的三个关键点
很多包发布后用户反馈“样式没生效”，其实不是代码问题，而是导出链路断在了发布配置环节。
- 确认
vite.config.ts的build.lib.entry指向的是包含 CSSimport的 JS 入口（如src/index.ts），而不是纯组件文件 - 检查生成的
dist/目录下是否真有 CSS 文件输出；如果没有，说明打包时未触发 CSS 处理逻辑 - 在用户项目中执行
npm install your-lib后，手动测试：import "your-lib";是否能正常加载样式；若报错，先看控制台是否提示Cannot resolve "your-lib/style.css"类错误
最常被忽略的一点：CSS 不是“装完就自动生效”的资源，它必须被 JS 入口显式拉入构建流程，且路径必须真实存在、可解析、未被摇树剔除——漏掉任一环，用户看到的就是白屏或样式错乱。
