应使用CSS Grid替代绝对定位实现列表项布局，因其支持自动换行、响应式调整、语义保留及无障碍访问；仅在需非网格化自由排布时才选用绝对定位。
绝对定位列表项时，top/left 值怎么动态计算才不重叠
直接用 top: 0; left: 0 所有 li 都会堆在左上角。必须为每个项算出唯一坐标。常见错误是手写固定值（top: 20px; left: 40px），一加新项就全乱。
核心思路：把列表索引 i 映射到二维坐标。比如每行放 4 个，则第 i 项的行号是 Math.floor(i / 4)，列号是 i % 4。
实操建议：
- 用 CSS 自定义属性传索引：
style="--i: 0;"、--i: 1;……再在 CSS 里用calc()计算位置，避免 JS 操控样式 - 若用 JS 动态设置，注意索引从 0 开始，且需监听
li增删——否则新增项没更新top/left - 行高/列宽单位统一用
px或rem，别混用%和px，calc(100% + 10px)会失效
用 CSS nth-child 实现纯 CSS 循环定位是否可行
可以，但有硬限制：只能写死有限项数。例如 12 个以内，能用 :nth-child(1) { top: 0; left: 0; }、:nth-child(2) { top: 0; left: 120px; }……但超过 20 项就不可维护。
立即学习“前端免费学习笔记（深入）”；
更实际的做法是组合使用：
-
:nth-child(-n+4)控制前 4 个为第 1 行（top: 0） -
:nth-child(n+5):nth-child(-n+8)控制第 5–8 个为第 2 行（top: 60px） - 列方向仍用
:nth-child(4n+1)、(4n+2)等设不同left
缺点：换布局（比如从 4 列变 5 列）就得重写整套选择器，且无法响应式自动适配屏幕宽度。
绝对定位后列表语义和可访问性还剩多少
视觉上排好了，但屏幕阅读器仍按 DOM 顺序读，不会感知你用 top/left 调整过位置。如果 DOM 顺序和视觉顺序不一致（比如视觉上第 2 行第 1 列实际是第 5 个 li），就会造成认知混乱。
关键判断点：
- 如果只是装饰性排列（如图标墙、时间轴节点），且内容本身无逻辑顺序，问题不大
- 如果是导航菜单、步骤流程、带编号的操作列表，必须保证 DOM 顺序 = 视觉阅读顺序，否则 WCAG 会失败
- 不能只靠
aria-order补救——该属性并不存在；可用aria-flowto显式指定阅读流，但支持度极低
替代方案：为什么 grid + grid-auto-flow: dense 更值得优先考虑
绝对定位看似灵活，实则绕过布局引擎，放弃响应式、对齐、间距自动计算等能力。而 display: grid 在循环排列场景下更稳：
- 用
grid-template-columns: repeat(4, 1fr)固定列数，新增项自动换行 - 需要“跳格”效果（如第 1 行第 2 列留空），加
grid-column: span 2即可，不用算像素 - 配合
@media改repeat(2, 1fr)就能响应式缩成两列，绝对定位得写 JS 重算 - 所有项仍保持文档流内，语义和可访问性天然保留
只有当需要非网格化自由排布（如放射状、螺旋、Z 字形）时，才真正需要绝对定位——其余情况，先试 grid，再决定要不要退回到 position: absolute。
