




CSS乱码根源在于HTML声明、CSS文件编码、HTTP响应头、构建链路四者不一致;须统一为UTF-8且避免BOM,禁用冗余@charset,配置服务器与构建工具编码参数。
浏览器解析 CSS 时,若 HTML 的 声明了 UTF-8,但外部 CSS 文件实际保存为 GBK(或 ANSI),就会出现中文注释、选择器名、content 值等显示为乱码。这不是引入方式(@import 或 )的问题,而是编码源头不一致。
实操建议:
位于 最前面,且没有其他 meta 冲突css-loader 或 rollup-plugin-css-only 是否默认按 UTF-8 读取——通常无需配置,但自定义 loader 时可能需显式指定 encoding: 'utf8'
@charset 声明时的优先级冲突@charset 是 CSS 规范中用于声明文件编码的规则,但它**必须是 CSS 文件的第一条语句**(前面不能有空行、BOM、注释),且一旦存在,就覆盖 HTML 的 meta 声明和 HTTP Content-Type 头中的字符集。
常见错误现象:
立即学习“前端免费学习笔记(深入)”;
div::before { content: "你好"; } 却显示方块或问号实操建议:
@charset "UTF-8";** ——现代浏览器默认按 HTML 的 charset 解析外部 CSS@charset(例如项目强制要求),确保它严格位于第一行、无空格、无 BOM:@charset "UTF-8";后面紧跟换行,不能有
/* 注释 */ 或空行Content-Type 覆盖 HTML 的 meta 声明当 CSS 通过 引入时,浏览器会发起独立 HTTP 请求获取该文件。如果服务器返回的响应头包含 Content-Type: text/css; charset=gbk,那么即使 HTML 和 CSS 文件本身都是 UTF-8,浏览器也会按 GBK 解析 CSS,导致乱码。
验证方法:
Content-Type
实操建议:
charset utf-8;(放在 http/server/location 块中)
AddCharset UTF-8 .css到
.htaccess 或虚拟主机配置res.set('Content-Type', 'text/css; charset=utf-8');使用 PostCSS、cssnano 或 Webpack 的 mini-css-extract-plugin 时,若输入 CSS 是 UTF-8,但插件内部读取/写入未指定编码,可能在生成 dist 文件时退化为系统默认编码(Windows 下常为 GBK)。
最容易被忽略的点:
postcss-scss)可能忽略编码参数css-loader 默认 encoding: 'utf8',但若配置了 url: false 或 esModule: false 等边界选项,个别版本存在编码继承异常fs.writeFileSync(cssPath, cssContent) 写入时,未传 encoding: 'utf8' 参数实操建议:
css-loader 设置:{ loader: 'css-loader', options: { encoding: 'utf8' } }from 和 to 路径,并确保 result.css 输出前调用 result.content.toString()(它会保留原始编码)encoding: 'utf8' 参数统一编码这事,表面看只是改个保存格式,实际要同时卡住 HTML 声明、CSS 文件存储、HTTP 响应头、构建链路四个环节——漏掉任意一个,乱码就可能冒出来。