现代HTML列表与复杂排版应坚持语义正确（用ul/ol/dl）+ CSS精准布局（Grid优于Flex），避免div硬凑、绝对定位滥用及margin模拟间距，注重可访问性、响应式与性能。
别用 <table> 做列表排版，也别靠一堆 <div> + float 硬凑复杂结构——现代 HTML 列表与复杂排版的核心，是语义正确 + CSS 布局能力精准匹配。
列表不是装饰，得用对语义标签
无序列表用 <ul>、有序列表用 <ol>、定义列表用 <dl>，这不是“可选习惯”，而是影响屏幕阅读器读序、SEO 解析和 CSS 选择器精度的关键。常见错误是把菜单、步骤说明、FAQ 全塞进 <div> 套 <p>，结果样式一改就乱，JS 操作也没法批量识别。
-
<dl>适合术语解释、属性列表等「键-值」结构，<dt>和<dd>必须成对出现，不能跳过或混用 - 嵌套列表合法但需克制：
<ul>里可以放<li>再包一层<ul>，但超过两层嵌套会显著增加可访问性负担 - 去掉默认列表符号后，别用
margin-left: -40px手动对齐文字——改用list-style: none+padding-left: 0，再通过display: flex或grid控制项内结构
复杂排版优先用 Grid，不是 Flex
当你要控制「行+列+区域跨度+响应式重排」时，display: grid 是唯一能直接表达二维意图的方案。Flex 本质是一维的，强行用 flex-wrap + 多层嵌套模拟网格，代码冗长、断点难维护、order 属性在嵌套中容易失控。
- 三栏仪表盘布局，用
grid-template-columns: 240px 1fr 320px比写三个flex: 0 0 240px+flex: 1+flex: 0 0 320px更直观、更易调试 - 避免滥用
grid-template-areas：名字写错一个，整块布局失效；改一个区域宽度，所有grid-area都要重写；实际项目中线性定义列宽/行高 + 单独用grid-column定位更稳妥 -
gap（或grid-gap）是栅格间距的唯一推荐方式，它不触发 margin 合并，也不受父容器overflow影响；而用margin模拟间距，在grid-auto-flow: dense下极易错位
响应式断点别只盯宽度，要结合内容密度
移动端不是简单“把三栏压成一栏”，而是根据内容可读性动态调整结构。比如新闻列表在桌面端用 3 列卡片，到平板可能缩为 2 列，但到小屏手机如果还硬撑 2 列，图片挤压、标题换行频繁，反而降低可读性——此时应切回单列，并提升 line-height 和 padding 补偿留白损失。
立即学习“前端免费学习笔记（深入）”；
- 媒体查询单位优先用
em或rem，而非固定px：字体缩放时布局不会断裂，适配系统级字号设置 - 用
@container（需检查浏览器支持）替代全局@media做局部响应：比如侧边栏卡片区宽度变化时，内部头图比例自动从 16:9 切到 4:3，不牵连主内容区 - 表格型数据在小屏必须可横向滚动，但别只加
overflow-x: auto：要包裹在有min-width: min-content的容器里，否则 Safari 会忽略滚动条；同时给<th>加position: sticky保证表头常驻
绝对定位只用于浮层，别当布局主力
把 position: absolute 用在主结构上，等于主动放弃文档流、可访问性和响应式基础。它该出现的场景非常有限：气泡提示、加载遮罩、右下角悬浮按钮、模态框 overlay。
- 绝对定位前，父容器必须设
position: relative（或其他非static值），否则定位基准是 viewport，不同设备下偏移量完全不可控 - 避免同时设
top和bottom期望拉伸高度：Chrome 和 Safari 在 zoom=125% 下行为不一致，inset属性虽简洁，但 Safari 15.4 以下不支持，生产环境慎用 - 如果 JS 动态计算位置（如 tooltip 跟随鼠标），务必监听
resize和scroll，并在元素display: none时清空style.left等内联样式，否则下次显示会残留错误坐标
最常被忽略的一点：复杂排版的性能瓶颈往往不在 CSS，而在 DOM 深度和重排频率。一个 <dl> 列表含 200 项，用 display: grid 渲染比用 flex 快 30% 以上——因为 Grid 的布局计算是离散的，而 Flex 在大量子项时需反复测量主轴空间。动手前，先想清楚这个结构是否真需要“复杂”。
