语义清晰的配送方式对比表需用<table>结构，<thead>含正确scope的<th>，运费与时效分列并明确单位与条件，窄屏改卡片布局，动态功能优先用CSS，复杂计算逻辑须解耦。
用 <table> 做配送方式对比，核心是语义清晰、结构可读
直接上手就能用的表格结构，不是为了“看起来像对比表”，而是让屏幕阅读器、搜索引擎和后续维护的人都能快速理解哪一行是“顺丰速运”、哪一列是“2kg以内”、哪个单元格代表“24小时达”。<thead> 必须有，<th> 要正确使用 scope 属性（scope="col" 或 scope="row"），否则在无障碍场景下会完全丢失行列关系。
常见错误：用 <div> 模拟表格、所有单元格都用 <td>、表头没包在 <thead> 里。这些写法会让表格在语音辅助工具中变成“一长串没标点的数据”，也增加 JS 动态操作成本。
-
<th>只用于真正意义上的表头（如“配送方式”“首重费用”“预计时效”），不要用它“加粗显示” - 横向对比项（如不同快递公司）放
<th scope="row">，纵向维度（如“0–1kg”“1–5kg”）放<th scope="col"> - 跨行/跨列用
rowspan和colspan，但别滥用——超过 2 行或 2 列合并时，建议拆成子表格或改用卡片布局
运费和时效字段怎么填才不误导用户
用户最怕看到“¥12起”却不知道“起”在哪档，“1–3天”却不说明是否含下单当天。HTML 表格本身不校验业务逻辑，但结构要为准确表达留出空间。
推荐把运费和时效拆成独立列，避免塞进同一个 <td>（比如不要写“¥8 / 24h”）。这样方便后续加 class 控制样式、用 JS 做筛选，也利于翻译或 A/B 测试。
立即学习“前端免费学习笔记（深入）”；
- 运费列统一单位：
¥12.00（两位小数），免费写成¥0.00或免费（保持列内一致） - 时效列明确是否含节假日：
工作日 24h、自然日 48h（含周末），避免只写“2天” - 如有例外规则（如“江浙沪次日达，其他地区+1天”），放在对应单元格末尾用
<small>或单独加注释列，不要藏在 title 里
响应式窄屏下表格不能简单缩放，得重构展示逻辑
手机上看 6 列宽的对比表，强行 overflow-x: auto 是最懒也最差的方案——用户得左右拖、放大、再拖，关键信息全被切掉。真正的响应式不是“让表格变小”，而是“换一种方式说清楚”。
可行做法：CSS @media 查询检测宽度，当 max-width: 768px 时，用 display: block 把每行 <tr> 变成垂直卡片；用 data-label 属性把列名存进去，CSS 生成伪元素标注字段（例如 td::before { content: attr(data-label) "：" }）。
- 不要依赖 JavaScript 来切换表格/列表模式，纯 CSS 更稳定、首屏更快
-
data-label值必须和<th>文本严格一致（如data-label="预计时效"），否则维护时容易错位 - 测试真机窄屏，重点看是否出现横向滚动条、文字是否折行错乱、点击区域是否足够大
需要动态计算或过滤？先确认是否真得用 JS 处理
如果只是静态展示几种固定配送方式，纯 HTML + CSS 完全够用。一旦加上“输入重量自动高亮最低运费”“勾选‘仅显示次日达’就隐藏其他行”，就得引入 JS，但要注意边界情况。
典型坑：用 innerHTML 直接拼接新表格，导致事件绑定丢失、XSS 风险；或监听输入框但没防抖，频繁重绘卡顿。
- 过滤逻辑优先用
Array.from(table.querySelectorAll('tbody tr'))获取行，再用dataset读取预设属性（如<tr data-fee="12" data-days="1">） - 运算结果写回 DOM 时，只更新
<td>的textContent，别动结构；高亮用 class 切换，别直接改 style - 如果运费规则复杂（如阶梯计价、满减叠加），把计算逻辑抽成独立函数，和渲染解耦——后期对接运费 API 时替换更安全
表格真正难的不是画线和对齐，而是把业务规则里那些“一般”“通常”“视情况而定”的模糊描述，转化成用户一眼能懂、系统能算、后续能改的确定性结构。
