根本原因是HTML、CSS文件与HTTP响应头的字符编码未统一为UTF-8；必须确保三者一致，并将content中文转为\7F51这类4位Unicode转义，同时显式声明中文字体族。
content里写中文直接乱码，是因为编码没对齐
根本原因不是CSS本身不支持中文，而是HTML、CSS文件、HTTP响应头三者的字符编码没统一成UTF-8。比如HTML用<meta charset="UTF-8">声明了，但CSS文件实际保存为GBK，或服务器返回Content-Type: text/css; charset=gbk，浏览器就会用GBK解码CSS——这时content: "网页链接"里的两个汉字被拆成4个字节，解析错位，轻则显示方框，重则整个规则失效（注释符号/*被截断、引号错配等）。
- 用编辑器（如VS Code）右下角确认CSS文件编码是
UTF-8 with BOM（不是无BOM的UTF-8） - 在CSS文件第一行**紧贴开头**加
@charset "UTF-8";（前面不能有空格、注释、BOM以外的任何字符） - 检查HTTP响应头，确保
Content-Type包含charset=utf-8；若用Nginx/Apache，需显式配置AddType text/css;charset=utf-8 .css
content中中文必须转Unicode，否则小程序/H5/APP三端表现不一致
即使编码统一，content: "网页链接"在微信小程序里可能渲染为空白，在iOS Safari里字体 fallback 失败，在部分Android WebView里触发代理对截断——因为各端对CSS字符串的Unicode解析逻辑不同。唯一稳妥方式是把中文转成\uXXXX格式的Unicode转义序列。
- Chrome控制台执行
escape('网页链接')得到%u7F51%u9875%u94FE%u63A5，再替换为\7F51\9875\94FE\63A5（注意去掉%u，保留反斜杠） - 不要用
\u7F51（ES6风格），CSS只认\7F51这种4位十六进制转义（\后跟4位，不足补0） - 遇到emoji或U+10000以上字符（如??），必须用双转义：先拆成代理对，再分别转义，例如
\uD83D\uDC69\u200D\uD83D\uDCBB→\D83D\DC69\200D\D83D\DCBB
font-family声明链缺失导致content文字“看不见”，而非“乱码”
很多人以为content里文字显示异常是编码问题，其实是字体fallback失败：content生成的伪元素默认继承父级font-family，如果父级设了"PingFang SC", "Helvetica Neue"而没加中文字体兜底，iOS会渲染，Android可能直接fallback到无中文的系统字体，结果就是空白或方框。
微信小程序 TabBar 图标生成技能，使用 Python PIL 绘制简约几何图标（未选中灰、选中绿），自动写入 app.json 配置。适用于“生成 tabBar 图标”、“底部菜单栏图标”、“tab 图标”等指令。
- 给伪元素显式声明字体：例如
div::before { content: "\7F51\9875"; font-family: "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", sans-serif; } - 避免用
"黑体""宋体"等中文名——不同系统拼写不一（Windows是SimHei，macOS是STHeiti），一律用英文别名 - UniApp等跨端框架需额外加
-apple-system和system-ui，确保iOS/macOS使用原生字体
小程序里content显示异常，本质是WebView限制而非CSS问题
微信/支付宝小程序的WebView对CSS content属性有隐性限制：不支持多字节Unicode直接写入、禁用某些字体特性、甚至对伪元素层级渲染有偏差。此时靠纯CSS无法解决，必须结合平台API。
立即学习“前端免费学习笔记（深入）”；
- 微信小程序中，优先用
text组件替代::before，通过data-属性传值，避免CSS解析环节 - 若必须用
content，确保转义后的Unicode字符串长度不超过12个字符（微信限制），超长需拆成多个伪元素 - 支付宝小程序需在
app.js中调用my.setStorageSync预加载字体文件，否则自定义字体在content中不生效
