border-spacing在chrome/firefox/safari现代版本中解析一致，均严格按“列距 行距”执行，不支持百分比和负值；差异仅存在于旧版本或特殊渲染场景（如safari缩放偏移、firefox rtl重映射）。
border-spacing在Chrome/Firefox/Safari中是否一致
绝大多数现代浏览器（Chrome 120+、Firefox 125+、Safari 17.5+）对 border-spacing 的解析完全一致：只要 border-collapse 计算值为 separate，两个长度值就严格按「列距 第一个值、行距 第二个值」执行，不支持百分比、负值，也不继承。
真正差异出现在旧版本或特殊渲染模式下：
- Safari 16.4 及更早版本在启用了
transform: scale()的父容器内，border-spacing可能被错误缩放（非整数缩放时出现 0.5px 偏移） - Firefox 在
table { direction: rtl; }场景下，border-spacing第一个值仍控制列间距（即物理左-右距离），但视觉上“左侧间隙”可能出现在右端——这不是 bug，而是 bidi 算法对间距坐标的重映射 - 所有浏览器对
border-spacing: 0的处理统一，但border-spacing: 0 0和border-spacing: 0在 DevTools computed 样式中显示不同（前者明确双值，后者单值展开），不影响渲染
cellspacing属性的兼容性陷阱
cellspacing 是 HTML 属性，不是 CSS，它的行为在所有浏览器中表面一致，但底层机制有隐性差异：
- 它强制触发
border-collapse: separate，但无法用 CSS 覆盖其值（border-spacing会优先于cellspacing） - IE11 及更早版本将
cellspacing="0"解析为「完全无间隙」，而 Chrome/Firefox/Safari 实际仍保留 1px 对齐容差（尤其在 subpixel 渲染开启时） - 当
cellspacing与border-collapse: collapse同时存在，HTML 规范要求忽略cellspacing，但部分旧版 Edge 会错误地保留其影响（表现为边框轻微错位） - 数值为
cellspacing="2"时，Chrome 渲染为 2px 物理像素；Safari 在 Retina 屏下可能渲染为 2.000001px，导致与其他元素 border 对不齐
为什么DevTools里看到的computed值有时不等于你写的
这不是浏览器 bug，而是层叠和计算逻辑导致的表观不一致：
- 第三方 UI 库（如 Ant Design v5.12）常通过
table { border-collapse: collapse !important; }锁死模式，此时你写的border-spacing直接被标记为invalid，即使源码里写了也无效 - CSS 自定义属性（
--cell-spacing-x）不能直接用于border-spacing，必须通过 calc() 或 JS 注入，否则 fallback 值不会生效 - 使用
rem单位时，根字体大小变化（如用户缩放、媒体查询切换）会导致 computed 值动态改变，但你在源码里写的仍是静态值 - 某些构建工具（Vite + CSS Modules）会自动添加哈希类名，若选择器权重不足（如只写
table），可能被全局样式覆盖，最终 computed 值来自更高优先级规则
跨浏览器调试时最该盯住的三个地方
别从头看代码，直奔这三个位置查：
- 打开 DevTools → Elements → 选中
<table> → Computed 面板 → 搜索 <code>border-collapse，确认其值是separate，且状态不是overridden - 同页面搜索
border-spacing，看 computed 值是否与你期望一致；若显示0px但写了8px，说明被collapse模式压制或选择器没命中 - 右键表格 → “View page source”，确认没有内联
cellspacing属性——它会静默覆盖你的 CSS，且无法在 Styles 面板里看到
真正在意像素级对齐的人，最后都会发现：问题不在 border-spacing 本身，而在它是否真的被浏览器执行。别的都能调，唯独这个前提漏了，后面全白忙活。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
