@import (css) 是唯一安全方式，因 Less 默认将所有 @import 当作 Less 源码解析，遇纯 CSS 规则（如 html { margin: 0; }）会因语法不兼容抛出 ParseError；必须置于主入口最顶部、配合 ~ 别名路径（如 @import (css) "~normalize.css/normalize.css"）才能正确跳过编译并原样输出。
@import (css) 是唯一安全的导入方式，直接 @import "normalize.css" 必然报错。
为什么直接 @import 纯 CSS 文件会报错
Less 默认把所有 @import 当作 Less 源码处理。遇到 html { margin: 0; } 这类纯 CSS 规则时，解析器会卡在语法上——比如属性值没引号、声明没分号、伪类写法不被识别，最终抛出 ParseError: Unrecognised input 或 SyntaxError。
- 错误现象：Webpack 构建中断，报错定位到
normalize.css第一行 - 不是路径问题，是解析模式错配：Less 在“编译”它，而不是“注入”它
- 哪怕文件能被找到，只要内容不符合 Less 语法规则，就必然失败
@import (css) 必须放在最顶部且带别名
加 (css) 修饰符后，Less 才会跳过编译，原样输出到最终 CSS 流中。但位置和路径写法稍有偏差，依然会失效。
- 必须写在主入口文件（如
main.less）的最顶部，早于任何变量、@import或样式规则 - 路径要能被构建工具正确定位：用
~normalize.css/normalize.css，而不是相对路径或裸文件名 -
@import (css) "normalize.css";仍可能失败——因为没走node_modules解析，也未声明别名 - 别名前缀
~是 Webpack/Vite 的能力，Less 本身不理解它，但less-loader会提前做路径替换
多个 CSS 文件共存时的冲突隐患
就算每个都用 @import (css)，如果项目里同时存在手写的 CSS 和 Less 编译出的 CSS，类名重复、优先级混乱、甚至样式覆盖不可控，仍是大概率事件。
立即学习“前端免费学习笔记（深入）”；
- 浏览器按
<link>加载顺序应用样式，而 Webpack chunk 分割可能打乱这个顺序 - 第三方 CSS（如 Ant Design）若没加
/* webpackIgnore: true */，可能被less-loader错误接管并尝试解析 - 不要在同一个项目里混用
style.css和index.less输出的样式——要么全走 Less 编译，要么关掉css-modules统一管理
真正难缠的不是语法报错，而是 @import (css) 成功后，样式却没生效——那八成是加载顺序或 specificity 被其他 CSS 覆盖了，得去 DevTools 里逐层查计算样式，而不是改 Less 文件。
