counter-reset在嵌套中不重置，根本原因是它仅在生成块框（block box）的元素上创建新计数作用域，而display: flex/grid/inline或float会使父元素无法形成bfc，导致子ul继承而非重置计数器；需显式设父li为display: block并在其上设置counter-reset。
counter-reset 在嵌套布局中不重置，通常不是浏览器 bug，而是作用域没被正确建立——它只在生成块级格式化上下文（BFC）的容器上才创建新计数作用域，而 display: flex、display: grid、float 或 display: inline 的父元素会切断这个上下文。
为什么 ul > li > ul 里的子 ul 不重置计数器？
标准规定：counter-reset 必须作用于「生成块框（block box）」的元素才能触发新作用域。但很多开发者误以为只要在子 ul 上写了 counter-reset: item;，它的 li 就会从 1 开始编号——实际上，如果父 li 是 display: inline 或用了 float，子 ul 可能不构成独立 BFC，导致计数器继承而非重置。
-
IE11及更早版本完全忽略嵌套counter-reset，只认最外层 -
Firefox严格按 BFC 触发重置，但Safari ≤16.6在display: flex的li内部ul中不创建新计数作用域 -
Chrome ≥112支持良好，但如果父li设了contain: layout，反而会隔离计数器，造成意外中断
如何强制建立可靠的计数作用域？
别依赖语义结构自动创建作用域。显式确保每个需要重置的容器是块级且独立渲染：
- 把
li设为display: block（避免inline/float导致的计数泄漏） - 禁用
li { display: inline }或float: left——它们会让li脱离文档流，破坏计数器继承链 - 不要对
ul设置display: inline-block；它不触发新计数作用域，Chrome/Firefox表现不一致 - 若必须用
Flex布局，把counter-reset移到li自身上，并用display: block保证其为块框：li { display: block; counter-reset: item; }
counters() 分隔符和多级嵌套的兼容陷阱
counters(item, ".") 在 IE11 中完全不支持，Safari ≤15.6 对多级嵌套的分隔符渲染错位（比如显示为 1..1 而非 1.1）。这不是语法错误，是实现缺陷。
- 安全写法：只在现代浏览器目标项目中用
counters()；否则降级为单级counter()+ 手动 HTML 层级标记 - 避免空格或中文作为分隔符：
counters(item, " → ")在旧Safari中会截断，推荐用英文点、短横或斜杠 - 不要嵌套调用：
counters(counters())—— 无浏览器支持，CSS语法直接报错 -
counters()第二个参数必须是字符串字面量，不能是CSS变量或属性值，例如counters(step, var(--sep))无效
动态插入或响应式切换时编号不更新怎么办？
counter-increment 是渲染时一次性触发的声明式行为，不监听 DOM 变化。JS 动态插入新元素后，即使样式规则匹配，也不会自动补计数——除非该元素被重新计算样式或强制重排。
- 临时修复：给新增元素加一个 class 触发重绘，例如
el.classList.add("force-repaint")，配合.force-repaint { animation: t 0.001s; } - 更稳方案：用
counter-reset重置整个容器，再让所有子项重新触发counter-increment（适合小批量更新） - 响应式场景下，
counter-reset不响应@media、display、visibility等状态变化；要实现“每组独立编号”，得把counter-reset明确放在每个逻辑分组容器（如.nav-group）上，而不是整个导航根容器
真正难的不是写对语法，而是判断哪个容器才是“真正起作用的计数锚点”——它必须是真实包裹目标元素的、生成块框的、未被 contain 或 display: contents 截断的 DOM 节点。刷新后编号消失、嵌套编号塌缩、伪元素里不显示，绝大多数都源于这一步没找对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
