Cookiecutter Django（Docker Compose部署）热重载随机失效排查

• 文件系统监听句柄耗尽
  Docker容器里的inotify有监听数量上限，项目文件一多就可能不够用，直接导致热重载失效。进容器执行cat /proc/sys/fs/inotify/max_user_watches看当前值，要是太低，就在local.yml的服务配置里加sysctls: fs.inotify.max_user_watches=524288来调高。

• 本地与容器的文件同步延迟
  不同系统的Docker挂载机制有坑：macOS的osxfs、Windows的WSL2挂载都可能出现文件事件传递不稳定的情况。试试换挂载模式，比如macOS用cached挂载，或者临时换成Docker Volume绑定，看热重载是否恢复正常。

• Django进程异常挂死
  有时候runserver进程看起来在跑，但内部的监听线程已经挂了，自然没法检测文件变化。进容器用ps aux看看进程状态，或者在local.yml里加个健康检查，定期访问个简单端点，确保服务真的在正常运行。

• 文件权限不匹配
  容器里的django用户可能没权限读你新创建的文件，导致热重载感知不到变化。检查容器内文件的所有者和权限，别让本地文件的权限带到容器里，确保进程用户能正常读写所有项目文件。

• IDE或工具的干扰
  有些IDE（比如PyCharm）的自动保存、重构操作会生成一堆临时文件，或者批量修改文件时把inotify事件冲没了。留意失效发生时你在做什么操作，试试关掉IDE的自动备份、临时文件生成功能再测试。

• 依赖服务异常牵连
  就算没改配置，数据库、Redis这些依赖服务出问题，也可能导致Django进程卡住，间接让热重载失效。翻容器日志看看有没有数据库连接错误、资源耗尽的报错，或者直接docker-compose down -v彻底清掉卷再重启。

• 代码语法错误导致重载失败
  要是你改的文件有语法错误，Django重载时会失败，之后就停止监听文件变化了。看容器日志里有没有语法报错，修复后重启服务就能恢复热重载。

内容的提问来源于stack exchange，提问作者Lev Slinsen