postcss-import默认启用skipDuplicates: true，通过哈希表记录已导入路径实现自动去重，避免多级引入重复解析和循环依赖；但路径必须完全一致，且需确保插件位于PostCSS链首位以支持layer和嵌套等后续处理。
postcss-import 默认就防重复导入，不用额外配置
它默认启用 skipDuplicates: true，内部用哈希表记录已处理的文件路径（比如 variables.css），同一路径被多次 @import 时只展开一次。这直接避免了多级引入中“父A → 子X”和“父B → 子X”导致的 X 被解析两遍的问题。
你不需要手动设 skipDuplicates，除非你要故意保留重复（比如覆盖样式优先级）。但要注意：路径必须完全一致——@import "./vars.css" 和 @import "src/vars.css" 在插件眼里是两个文件，都会被加载。
- 检查你的 import 路径是否标准化（统一用相对路径或统一走 node_modules）
- 避免混用别名路径和真实路径（如
@import "~styles/vars.css"和@import "src/styles/vars.css"） - 循环依赖（A → B → A）下，该机制也能终止递归，防止卡死
多级引入本身不慢，慢在构建后仍生成单个大 CSS 文件
postcss-import 是开发期组织工具，不是运行时优化方案。它把 header.css → button.css → reset.css 展开成一个长文件，但这个长文件仍是浏览器阻塞渲染的资源。
常见误操作：以为“合并 = 加快首屏”，结果 Lighthouse 显示 “Eliminate render-blocking resources”，Network 面板里 app.css 下载耗时飙升。
立即学习“前端免费学习笔记（深入）”；
- 真正要解决的是“哪些样式必须首屏就用”，而不是“怎么全塞进一个文件”
- 用打包器（Vite/Webpack）拆 chunk，把非关键样式（如弹窗、评论区）抽成异步 CSS
- 关键样式（
critical.css）内联进 HTML，其余用<link rel="preload" as="style" onload="this.rel='stylesheet'">
插件顺序错，多级嵌套和 layer 就失效
如果你在子文件里写了 @layer components 或嵌套语法（&.btn { &--primary {} }），而 postcss-import 不在插件链最前面，这些结构会在传给 postcss-nesting 或 postcss-layers 前就被提前扁平化。
错误配置示例：require('postcss-nesting') 放在 require('postcss-import') 前面 → 子文件里的 & 会被当成普通字符，嵌套规则丢失。
- 必须保证
postcss-import是第一个插件 - 后续插件（
postcss-nesting、postcss-layers、autoprefixer）才能拿到完整合并后的 AST - 路径解析也依赖它前置：它先 resolve 所有
@import，后面插件才处理合并结果
node_modules 中的 CSS 模块，别手动配 root
很多人为了导入 normalize.css 或组件库样式，在 postcss-import 配置里写 root: "node_modules"。这反而破坏默认解析逻辑——插件本就会按 Node.js 模块规则查找 node_modules/xxx/dist/index.css 或 package.json#main 字段。
手动指定 root 容易导致路径解析失败，尤其当包里没导出 index.css 而是 style.css 时。
- 删掉
root配置，让它走默认逻辑 - 需要额外路径（比如项目里自定义的
src/css/lib）再用path选项追加 - 远程 URL（
@import "https://..."）不会被处理，原样保留——这是设计行为，不是 bug
postcss-import 当成“构建优化工具”来用。它解决的是模块组织和开发体验问题，真正的性能瓶颈从来不在导入层级，而在资源加载时机和粒度。 
