整理一份长文档的时候卡在id如何自动编排页码，反复拖拽调整，改一次内容，后面的编号就乱掉，折腾了快大半个下午。之前一直手动敲数字，删一行或者插一段，就得顺着往后挨个改，改到后面眼睛发花，还总漏掉一两个序号，交付的时候被打回来好几次。
最开始想的办法很简单，直接给每一条内容写上固定的数字，觉得内容变动不多，稍微改改就行。那次是往中间插入三条记录，前面的id不动，后面所有编号全部错位，改完一遍，往下滚动又发现还有漏掉的，越改越烦躁，索性停下来去找别的路子。网上零散的说法很多，有的说用脚本，有的说靠表格自带序列，试了脚本那套，环境配起来麻烦，稍微改下结构脚本就跑不起来，不适合我这种经常临时调整文档结构的场景。
后来才反应过来，不用写复杂代码，把id和样式绑定在一起，依靠样式规则去生成编号，新增、删除条目之后，刷新一下，页码序列自己就顺下来了。设置的时候，先给容器开启计数器，再给目标元素绑定计数器自增，元素渲染的时候，自动读取这个计数作为id，和页码同步走。顺序跟着文档流走，条目挪动位置，编号也跟着挪，不会死死钉在写好的数字上面。
有个细节容易忽略，计数器的重置位置放错，编号就会从头重新开始。一开始把重置写在了子元素里面，每生成一条就重置一次，结果所有id全变成1，盯着屏幕愣了好久，反复比对代码才发现问题。重置只需要放在最外层父容器，子元素只负责计数叠加，这样整套序列才是连贯的。
分页切换的时候也出过状况。
换页之后计数器没有延续上一页末尾的数字，新页面又从1重新排，等于每页单独一套编号，和想要的连续自动编排不是一回事。调整了一下，不按分页容器重置，计数器全局持续累加，分页只是视觉上切割页面，底层计数不会中断，翻页之后id顺着前面的数字继续往下走，页码和id就能保持对应。
这只是我的个人感受，不是标准答案。我这套方式只适配我当下这种静态文档排版的场景，如果是动态加载大量数据的页面，可能就不太合适，别人的使用环境不一样，出来的效果也会有差别。
还有一点，嵌套层级不能太深。嵌套两层以内还好，层级一多，计数器的作用域会互相干扰，内层和外层的计数混在一起，编号跳号、重复都有可能出现。遇到嵌套列表多的文档，我一般会拆成独立的容器，分开设置不同名字的计数器，互不干扰，只是维护的时候要多留意容器划分。
试过把这套写法复制到别的文档里，有的编辑器支持伪元素生成计数，有的编辑器渲染规则不一样，直接识别不了，复制过去之后id直接不显示。碰到这种情况，也没有硬磕，换成别的编排方式，没有非要在一个工具里面死磕。
写到后面，慢慢摸清边界，它省事的地方是增减条目不用手动改号，麻烦的地方是对编辑器渲染能力有要求，也扛不住特别复杂的嵌套结构。现在日常做文档，结构简单的长列表就用这个办法，结构复杂、平台兼容性差的，干脆回到手动编号，省得花更多时间去调试计数器。
那天调试完，保存好样例片段，直接把之前手动编号的文档关掉，不想再对着一串数字来回修改。