@import (inline) 将文件内容原样嵌入CSS输出，不解析Less语法、不转义字符、不校验CSS合法性，适用于引入带BOM或含CSS自定义属性的reset.css等场景。
@import (inline) 会原样把文件内容塞进输出CSS里
它不解析 Less 语法，也不转义 CSS 特殊字符，只是读取文件、拼进去。适合你只想“把这段 CSS 原封不动塞进最终样式表”的场景，比如引入一个带 BOM 或含 CSS 自定义属性的 reset.css，又不想被 Less 解析器报错。
为什么用 @import (inline) 而不是默认 @import
默认 @import "reset.css" 会被编译成一条 @import url("reset.css") 的 CSS 规则——浏览器得再发一次 HTTP 请求；而 @import (inline) "reset.css" 把整个文件内容直接展开进当前 CSS 输出中，零请求、可压缩、便于部署。
- 常见错误：写成
@import (inline) "reset.less"却期望变量生效 → 不会，inline模式下所有@开头的语法（包括变量、mixin）全被当普通文本处理 - 典型误用：在
inline导入的 CSS 里写了// 注释→ Less 不识别 CSS 风格的双斜杠注释，会直接透出到输出中，可能破坏样式或引发兼容问题 - 路径必须准确：Webpack/Vite 环境下，
@import (inline) "./node_modules/normalize.css/normalize.css"可能失败，推荐先用别名或~（如@import (inline) "~normalize.css/normalize.css"），并确认 loader 配置支持该别名
@import (inline) 和 @import (css) 的区别在哪
二者行为几乎一致：都不解析 Less，都原样内联内容。但关键差异在于语义和容错：
-
@import (css) "file.css"：强制按 CSS 解析，遇到非法 CSS（比如漏了}）会报错，且会尝试处理@charset、@import等 CSS at-rules -
@import (inline) "file.css"：完全跳过语法校验，连注释、BOM、不可见控制字符都照单全收，更“粗暴”但也更可靠——尤其对付 Windows 下保存的带 BOM 的 CSS 文件 - 如果你导入的是纯 CSS 且格式规范，两者效果一样；如果文件来源不可控（比如 npm 包里的 CSS），优先选
inline
搭配 Webpack 时容易漏掉的关键配置
Less-loader 默认不会把 @import (inline) 的目标文件纳入依赖追踪，改了第三方 CSS 内容，Webpack 不会触发重编译。
立即学习“前端免费学习笔记（深入）”；
- 解决办法：在
less-loader的options中加additionalData或用webpack.LoaderOptionsPlugin手动声明依赖，但更简单的是——改用postcss-import+@import语句（不带inline），由 PostCSS 阶段接管，天然支持依赖追踪和别名解析 - 另一个坑：
inline导入的内容无法被autoprefixer处理，除非你把它放在postcss-loader之后（但那就违背了 inline 的本意）；真需要加前缀，应避免用inline，改走@import (less)+ 合法 CSS 写法
真正难搞的从来不是语法本身，而是你不知道那个带 BOM 的 normalize.css 正在悄悄让 Less 解析器卡在第一个字节上——inline 是绕过它的最短路径，但代价是放弃所有编译期能力。
