根本原因是border-collapse默认值和box-sizing处理逻辑差异：Chrome/Firefox默认separate，Safari可能激进合并边框；同时border-spacing未重置、混用cellpadding与CSS padding、th/td基线差异及Outlook内联样式限制共同导致渲染不一致。
为什么同一段 padding 在 Chrome 和 Safari 里看起来不一样
根本原因不是浏览器“渲染错误”，而是 border-collapse 默认值和 box-sizing 处理逻辑不同。Chrome 和 Firefox 默认用 border-collapse: separate，Safari（尤其旧版）在某些文档模式下可能更激进地合并边框；而所有浏览器对 td { padding: 8px; } 的解析虽一致，但若同时存在 border 和未重置的 border-spacing，视觉间距就会发散。
关键检查点：
- 用 DevTools 查看 computed 样式中
border-collapse真实值，不是声明值 - 确认
table元素上没意外继承或被框架注入border-spacing - 避免混用
cellpadding和 CSSpadding——一旦有任意一条td { padding: ... }，cellpadding就彻底失效，且不报错
td 和 th 的 padding 必须分开写才可靠
很多团队统一写 td, th { padding: 6px 12px; }，结果表头文字垂直居中偏上、数据行文字贴底。这不是 bug，是 th 默认有 font-weight: bold 和不同行高，导致基线位置不同，padding 虽然数值一样，但视觉重心不一致。
稳妥做法：
立即学习“前端免费学习笔记（深入）”；
-
th { padding: 10px 12px 6px; }—— 上多留点空间压住加粗字体的视觉膨胀 -
td { padding: 6px 12px; }—— 下方留白更少，保持行高紧凑 - 若需严格等高，加
vertical-align: middle;到两者，并配line-height: 1.4;
邮件客户端和旧版 IE 的内联 style 是唯一兜底方案
Outlook（尤其是基于 Word 渲染引擎的版本）会直接忽略 <style> 块里的 td 样式，哪怕你写了 !important。它只认内联 style，且对单位敏感：支持 px，不支持 rem 或 %。
兼容性写法示例：
<td style="padding: 8px 12px;">内容</td>
注意：
- 不要写
padding-top单独属性——Outlook 部分版本只识别四值简写 - 避免
calc()、em、vh等现代单位，它们会被静默丢弃 - 如果必须响应式，只能靠媒体查询 + 内联
style动态注入（需后端或 JS 支持）
border-collapse: collapse 后必须显式设 border-spacing: 0
这是最常被跳过的一步。border-collapse: collapse 本身不会清掉 border-spacing，只是让它的作用失效；但某些浏览器（如 Safari 16 及更早）在表格重绘时仍会读取该值并微调布局，导致单元格宽度抖动或右侧出现 1px 缝隙。
正确组合：
table { border-collapse: collapse; border-spacing: 0; }td, th { padding: 8px; }- 别给
tr设padding——无效，且部分老浏览器会报 layout warning
真正麻烦的从来不是“怎么加 padding”，而是加完之后发现打印预览错位、移动端缩放后文字贴边、或者合并边框后内边距被视觉压缩——这些几乎都源于没同步处理 border-spacing 和 box-sizing。动手前先扫一眼 computed styles 里的 actual padding 值，比猜更可靠。
