根本原因是编码不一致导致css解析失败：utf-8文件被误按gbk等编码解析，使中文注释无法闭合、counter-reset等声明被截断或吞掉；需确保@charset声明在首行、文件保存为utf-8 without bom，并正确设置counter作用域容器。
不是 CSS 变量导致乱码，而是乱码让 counter() 等声明失效——根本原因是编码不一致，CSS 解析器读错字节，把 counter-reset 或中文字符串当成非法 token 吞掉或截断。
乱码直接破坏 CSS 语法结构
一个中文字符在 UTF-8 中占 3 字节，若文件被当作 GBK 或 ISO-8859-1 解析，就会拆成两个“半个汉字”，比如 /* 图表编号 */ 可能变成 /* 涓у浘琛ㄧ紪鍙 */，注释无法闭合，后面所有规则被吞进注释里；同理，counter-reset: fig; 若前面有乱码残留，可能被截成 counter-r，整行作废。
-
@charset "utf-8";必须写在 CSS 文件第一行（包括 BOM 前），否则浏览器按默认编码解析 - 编辑器保存时确认编码为 UTF-8 without BOM（VS Code / Sublime 默认带 BOM，Obsidian 插件易出问题）
- 避免在 CSS 中写中文注释、中文字体名（如
font-family: "黑体"），改用英文或别名（"SimHei"）
Obsidian 或 Markdown 渲染器中额外风险点
Obsidian 的 CSS 片段注入到已有 DOM 中，若其主样式表或主题 CSS 存在乱码，会污染整个样式作用域——哪怕你自己的 snippet 没乱码，counter-reset 也可能因上游解析失败而未生效，最终所有 counter() 回退到默认值或显示为空。
- 检查 Obsidian 设置 → 外观 → CSS snippets 目录下所有 .css 文件是否都以 UTF-8 without BOM 保存
- 禁用第三方主题/插件临时测试，排除外部样式表干扰
- 用浏览器开发者工具的 “Computed” 面板查看目标元素是否真的应用了
counter-increment，若没出现，说明该规则根本没被解析
为什么 counter() 显示 “1” 却疑似乱码？
这不是乱码，是计数器作用域错误的典型表现：所有元素都从 1 开始，说明 counter-reset 没在正确容器上触发新作用域，而是全局重置或未重置。此时你看到的 “1” 是干净的数字，但逻辑错了。
- 别在
body上设counter-reset（Obsidian 中尤其危险） - 每个独立编号区块（如一张图、一节 Markdown heading）必须包裹在显式
display: block容器内，并在其上写counter-reset: fig; - 确保该容器没有
contain: layout或display: contents——它们会切断计数作用域
真正要盯住的不是变量，是文件编码和作用域锚点。一旦 @charset 和容器块级语义到位，counter() 就不会“乱”，只会“错”——而“错”是可调试的，“乱”是解析器已经放弃治疗了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
