乱码本质是浏览器用错编码解析css字节流；核心只需确保构建产物为utf-8 without bom，且http响应头明确声明content-type: text/css; charset=utf-8，@charset在tailwind项目中基本无效。
乱码不是 Tailwind 生成了错误字节，而是浏览器用错编码读取了最终 CSS 文件；核心只看两点：CSS 文件是否为 UTF-8 without BOM，以及 HTTP 响应头是否明确声明 Content-Type: text/css; charset=utf-8。
@charset "UTF-8" 在 Tailwind 项目里根本没用
Tailwind 默认不生成 @charset 声明——它依赖构建工具（如 PostCSS）输出时的编码配置。即使你手动在入口 style.css 里写了 @charset "UTF-8";，只要它不在第一行、或前面有 BOM/空格/注释，就立即失效；而 Tailwind 的 @tailwind base 等指令会插在最前面，天然挤掉 @charset 的位置。
- 别在
style.css里硬加@charset：Tailwind 构建流程会重排规则顺序，@charset几乎必被覆盖 - PostCSS 输出编码由
cssnano或postcss自身控制，不是靠 CSS 源码里的声明 - 真正起效的是构建后产物文件本身的编码格式 + 服务器响应头
Vite / Webpack 构建后 CSS 文件仍是乱码？先查文件编码
构建工具默认按 UTF-8 读取源文件，但若你用了自定义 loader、拼接逻辑或旧版插件，可能中途误转成 GBK。最终产出的 dist/style.css 必须是 UTF-8 without BOM。
- 用
xxd dist/style.css | head -1检查开头三字节：不能出现ef bb bf（BOM） - VS Code 打开
dist/style.css，右下角确认编码显示为 “UTF-8”，且无 “with BOM” 字样 - Webpack 用户检查
css-loader配置是否显式设了encoding: 'utf8'；Vite 用户一般无需干预，但若用了vite-plugin-css-injected-by-js类插件，需确认其注入逻辑未改变编码
本地开发正常，上线后 CSS 中文乱码？盯死 Nginx / CDN 响应头
Tailwind 构建产物没问题，但服务器返回的 Content-Type 是 text/css; charset=gbk，浏览器就强制用 GBK 解析 UTF-8 字节流，中文立刻变方块或错位。
- Chrome DevTools → Network → 找到
style.css请求 → Headers → Response Headers → 确认Content-Type含charset=utf-8 - Nginx 配置必须加
charset utf-8;（注意不是charset gbk;），且放在location块内，避免被上级配置覆盖 - CDN（如 Cloudflare、阿里云）可能强制注入
charset=gb2312，需进控制台关闭“自动编码识别”或显式设置响应头 - 用
curl -I https://yoursite.com/style.css实测，比浏览器界面更准
最容易被忽略的是：Tailwind 本身不碰编码，乱码永远发生在“构建产物落地”和“HTTP 响应发出”这两个环节；前者查文件十六进制，后者查响应头，中间任何一环掉链子，@charset 就是摆设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
