根本原因是CSS文件编码与HTML声明字符集不匹配，导致浏览器错误解析伪元素content值；应统一使用UTF-8无BOM编码，优先直接写中文，必要时用单个\XXXX转义，构建工具和服务器配置需确保编码一致。
伪元素content中文显示为方块或问号
根本原因是 CSS 文件保存编码和 HTML 声明的字符集不匹配，浏览器按错误编码解析 ::before 或 ::after 中的 content 值。
- 常见现象：CSS 里写
content: "编辑";，页面却显示 □□ 或 ，但 HTML 内文本正常 - 典型场景：用 VS Code、Sublime 等编辑器保存 CSS 文件时默认用了 UTF-8 with BOM，而 HTML 没声明 BOM 或用了无 BOM 的 UTF-8
- 检查方法：用命令行
file -i style.css（Linux/macOS）或查看编辑器右下角编码标识；确认 HTML 有无<meta charset="UTF-8"> - 解决动作：统一为「UTF-8 无 BOM」——在编辑器中另存为时取消勾选 “BOM” 选项，不是简单改后缀或重写 meta
content里用\5C0F\4F1A乱码转义反而更糟
这是把 Unicode 转义当万能解药，结果适得其反。CSS 规范只支持 \XXXX 十六进制转义（如 \4F1A），而 \5C0F\4F1A 这种写法会被解析成两个独立转义，中间若夹杂空格或换行，直接中断解析。
- 错误示例：
content: "\5C0F\4F1A";→ 实际只读到\5C（反斜杠字符），后面被丢弃 - 正确做法：优先用原生 UTF-8 字符，只要文件编码对，
content: "小会";最简洁可靠 - 必须用转义时，严格按单个四字符十六进制写：
content: "\4F1A";（仅用于特殊符号或避免编辑器保存问题） - 注意：转义不解决编码不一致问题，只是绕过部分编辑器 bug，治标不治本
Webpack/Vite 构建后 content 乱码
构建工具可能对 CSS 做了编码重写或压缩，尤其启用 cssnano 或旧版 mini-css-extract-plugin 时，默认会 strip BOM 或强制转码。
- 排查点：检查构建配置中是否启用了
encode、convertValues类似选项；Vite 用户留意build.cssCodeSplit是否触发了非预期处理 - 实操建议：在
vite.config.ts中加css: { transformer: 'lightningcss' }（新版 Vite 默认），或 Webpack 中禁用 cssnano 的normalizeWhitespace - 验证方式：构建后直接打开 dist 目录下的 .css 文件，用编辑器查看编码和内容是否仍为原样 UTF-8 无 BOM
内联 style 标签里的 content 不乱码，外部 CSS 就乱
说明 HTML 页面本身编码没问题，问题锁定在外部 CSS 文件加载环节——浏览器按 HTTP 响应头或 <link> 的 charset 属性决定解析方式，而非 HTML 的 meta。
立即学习“前端免费学习笔记（深入）”；
- 关键检查项：用 DevTools 的 Network 面板看 CSS 请求的 Response Headers，确认
Content-Type是否含charset=utf-8 - 常见坑：本地开发用 file:// 协议时，浏览器完全忽略 meta，只依赖文件 BOM 或系统默认编码
- 稳妥方案：给
<link>显式加charset="utf-8"（尽管 HTML5 已不推荐，但对旧浏览器和 file:// 场景有效） - 服务器部署时：Nginx/Apache 需配置
add_header Content-Type "text/css; charset=utf-8";，不能只靠文件后缀
真正卡住人的从来不是“怎么写 content”，而是构建链路里某一层悄悄改了编码——比如 CI 流水线用不同 locale 的 Docker 镜像保存 CSS，或者 Git 自动转换了行尾再顺手改了编码。盯住文件实际字节，别信编辑器右下角的小字提示。
