在 tailwind.config.js 的 theme.spacing 下直接添加键值对即可扩展自定义 spacing，如 '1.5': '0.375rem'，支持 mt-1.5 等工具类；需用字符串键名（带引号）、合法长度单位值，修改后重启 dev server。
tailwind.config.js 里怎么加自定义 spacing 数值
直接在 theme.spacing 下扩展对象就行，不是覆盖整个 spacing，而是合并进去。Tailwind 默认的 spacing 是一个对象（比如 { '1': '0.25rem', '2': '0.5rem', ... }），你往里面加新键值对，就能用 mt-[key] 这类工具类。
常见错误是写成数组、或误改 theme.extend.spacing 却忘了它默认是空对象——结果啥都没加进去。
- 必须写在
theme.spacing下，theme.extend.spacing只在你需要保留默认值又不想污染主对象时才用（但多数情况直接写theme.spacing更直白） - 键名会变成 class 名的一部分，比如加
'1.5': '0.375rem'，就能用ml-1.5；注意点号要加引号，否则 JS 解析报错 - 值推荐用 rem 或 em，避免 px（响应式退化）、也不要用百分比（计算复杂且易出错）
为什么有些自定义 spacing 编译后没生成对应 CSS
最常见原因是 key 名含非法字符，或者值不是合法 CSS 长度单位。Tailwind 的 JIT 引擎只认它能静态分析出来的值，动态拼接、变量引用、函数调用全都不行。
比如写 'xs': 'calc(1rem - 2px)' 看似合理，但 Tailwind 不解析 calc 表达式，最终不会输出 .p-xs 类；再比如用 '2xl' 当 key 却没在别的地方用到 padding-2xl，JIT 模式下也不会生成——它按需生成。
立即学习“前端免费学习笔记（深入）”；
- 确保 key 是字符串字面量（
'4.5'✅，4.5❌） - 值必须是纯字符串，且为浏览器可识别的长度单位：
'0.125rem'、'2px'、'10vh'都可以，em和rem最稳妥 - 修改配置后记得重启 dev server，HMR 不会自动 reload tailwind.config.js
用 theme.spacing 扩展时和插件/第三方库的兼容性问题
只要第三方插件没硬编码覆盖 theme.spacing，就基本没问题。但要注意：某些 UI 库（如 @headlessui/react）的组件内部用了固定 spacing 值（比如写死 gap-2），你改了 spacing.2，它就跟着变——这是优点也是风险点。
更隐蔽的问题是设计系统一致性：如果你把 '3' 改成 '0.625rem'（原为 '0.75rem'），所有用 mb-3 的地方都会收缩，可能破坏已有布局。别只想着“加新值”，改旧值前先全局搜一遍。
- 新增 spacing 推荐用语义名（
'safe-area'、'nav-height'）而非纯数字（'7.5'），方便团队理解 - 如果项目已用大量
space-y-*，注意space-y也依赖theme.spacing，改了会影响子元素间隙 - 用
@apply的地方同样走 spacing 配置，比如@apply p-4里的4也会被你新配的spacing.4影响
想让某个组件专用间距不污染全局 spacing 怎么办
不推荐为单个组件开一套 spacing，容易失控。更实际的做法是：用 addUtilities 写局部 utility，或直接上内联 style。
比如卡片内边距要精确控制为 12px，又不想让全局 spacing.3 变成 12px，那就单独注册一个 class：
addUtilities({
'.p-card': { padding: '12px' }
})这样既隔离了作用域，又不干扰 JIT 编译逻辑。
-
addUtilities写在plugins: []里，不是theme下 - 避免用太泛的 class 名（如
.p-12），容易和未来 Tailwind 原生值冲突 - 如果只是临时调试，用浏览器 devtools 直接改
style属性更快，别急着配进 config
Tailwind 的 spacing 配置看着简单，真正卡住人的往往是 key 的引号、JIT 的按需生成逻辑、以及改了之后全项目连锁反应——这些地方没留神，调半天才发现 class 根本没生成。
