counter-reset在复杂嵌套中失效，根本原因是它仅在生成块框（block box）的元素上才创建新计数作用域；display:inline、float、flex或grid容器可能使子元素脱离默认计数上下文，导致继承而非重置。
counter-reset 在复杂嵌套列表中失效，不是你写错了，而是浏览器对计数器作用域的理解不一致——它只在「块级容器」内生效，而 display: inline、float、flex 或 grid 容器里的子元素可能脱离默认计数上下文。
为什么 counter-reset 在 ul > li > ul 里不重置？
标准规定：counter-reset 必须作用于「生成块框（block box）」的元素才触发新作用域。但很多开发者误以为只要写了 counter-reset: item; 在子 ul 上，就能让它的 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，反而会隔离计数器，造成意外中断
用 display: block 强制建立计数作用域
别依赖语义结构自动创建作用域。显式确保每个需要重置的 ul 是块级且独立渲染：
li {
display: block; /* 避免 inline/float 导致的计数泄漏 */
}
ul {
counter-reset: item;
}
li::before {
counter-increment: item;
content: counters(item, ".") " ";
}- 禁用
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 语法直接报错
用 @supports 安全启用嵌套计数器
不能靠 UA 判断，得检测能力。CSS 计数器嵌套依赖 counters() 和作用域重置的组合支持：
@supports (content: counters(item, ".")) and (counter-reset: item) {
ul { counter-reset: item; }
li::before { content: counters(item, ".") " "; counter-increment: item; }
}-
@supports检测必须同时包含content: counters()和counter-reset，缺一不可——有些浏览器支持重置但不支持多级显示 - 不建议用 JavaScript 动态插入计数器逻辑：DOM 深度大时性能差，且无法响应 CSS 媒体查询变化
- 真正难搞的是「动态插入的子列表」：JS append 的
ul不会自动触发counter-reset，必须确保插入后该元素已参与 CSS 渲染流程（如强制offsetHeight读取）
最易被忽略的一点：计数器名区分大小写，且 counter-reset: Item; 和 counter-increment: item; 不匹配——这种低级错误在嵌套层级深时极难定位。
