容器中无“Using JIT”提示，根本原因是inotify事件在Docker中默认不可用，导致Tailwind监听失效而退化为全量编译；需加--poll参数或配置fs.inotify.max_user_watches，并确保content路径、PostCSS插件链及挂载映射在容器内正确生效。
为什么容器里看不到“Using JIT (Just-In-Time) mode”提示
根本不是 JIT 没装，而是 inotify 事件在 Docker 容器中默认不可用，Tailwind 的文件监听器收不到变更信号，只能退化为全量重编译。终端不显示 Using JIT (Just-In-Time) mode，说明它压根没进入 watch 流程。
- Linux 主机上运行
docker run --privileged或加--sysctl fs.inotify.max_user_watches=524288可缓解，但非根本解 - 更可靠的做法是强制轮询：在启动命令里加
--poll参数，例如npx tailwindcss -i ./src/input.css -o ./dist/output.css --watch --poll - Vite/Next.js 等工具链若封装了 Tailwind CLI，则需通过环境变量透传，如
TAILWIND_MODE=watch+TAILWIND_POLL=true（部分版本支持）
content 路径在容器内失效的常见原因
路径本身没错，但在容器挂载场景下，content 数组里写的 ./src/**/*.{ts,tsx} 可能指向宿主机路径，而 Tailwind 运行在容器内，实际读的是空目录或旧缓存。
- 确保挂载时路径对齐：Docker volume 映射必须覆盖
tailwind.config.js所在目录及其content中声明的所有源码路径 - 避免使用相对路径如
../src—— Tailwind 解析content基于配置文件所在位置，容器内工作目录错位会导致扫描失败 - 验证方式：进容器执行
ls -R ./src，确认输出与本地一致；再手动运行npx tailwindcss --content "./src/**/*.{ts,tsx}" --dry-run，看是否列出你刚写的 class
PostCSS 插件链在容器中被静默跳过
很多 CI/CD 或远程开发镜像会精简依赖，postcss 或 postcss-cli 缺失时，Tailwind 插件不会报错，而是直接跳过，导致 CSS 文件不更新。
- 检查容器内是否安装
postcss：运行npm ls postcss，输出应包含postcss@8.x（v3+ Tailwind 强依赖） - 确认
postcss.config.js存在且插件顺序正确：tailwindcss必须是第一个，不能被cssnano或autoprefixer提前截断 - Next.js 用户尤其注意：删掉项目根目录的
postcss.config.js—— 它会覆盖框架内置配置，禁用 JIT 自动路径推导
动态 className 在容器开发中更难调试
本地跑得通的模板字符串拼接，放到容器里热更新更慢，不是因为网络延迟，而是 JIT 静态分析失败后，全量重编译耗时被放大。
-
className={`p-${size}-4`}这类写法在任何环境都不被 JIT 识别，容器里只是把“失效结果”暴露得更明显 - 临时兜底可用
safelist：比如safelist: [/p-(sm|md|lg)-4/]，但别长期依赖，体积和维护成本会上升 - Vite 用户注意：若用了
esbuild预处理 JSX，容器内 Node 版本略低时可能解析失败，导致 AST 提取为空 —— 改用babel或显式启用jsx: 'automatic'
真正卡住的从来不是 JIT 本身，而是容器文件系统与构建工具链之间那层看不见的适配断点。每次改完样式要等 3 秒以上，大概率不是 CPU 不够，是 inotify 没通、路径没对上、或者 PostCSS 根本没跑起来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
