Azure Web App部署时代码从tmp复制到wwwroot间歇性失效问题

从Oryx构建日志和Azure Web App的底层运行逻辑看，/tmp目录部署稳定但wwwroot偶发复制失败，是多层机制共同导致的概率性问题，和GitHub Actions配置、项目代码本身没有直接关系：

• 存储介质差异：/tmp是部署实例本地的SSD临时存储，读写延迟低、稳定性高；而/home/site/wwwroot挂载的是Azure底层的网络共享持久化存储，本身存在小概率的IO闪断、连接超时。Oryx日志里的「Copied the compressed output」仅代表压缩包写入接口返回成功，不会对写入后的文件做完整性校验，一旦出现网络闪断导致压缩包残缺、解压不全，日志不会报任何错误，表面看就是文件没复制到位。
• 运行时文件锁冲突：如果部署动作触发时应用进程还在正常运行，gunicorn/uvicorn等服务进程会持有wwwroot下已加载的Python字节码文件、静态资源、日志文件甚至本地sqlite数据库的文件句柄。Oryx覆盖写入文件时碰到被持有的句柄，不会重试也不会抛出显性错误，直接跳过对应文件的写入，就会出现新文件缺失、旧文件残留的情况。这个问题完全是概率性的：部署瞬间如果进程刚好持有对应文件句柄就触发，否则就正常。
• Oryx流程缺少校验步骤：从日志可以看到，Oryx的构建流程是先把产物写到临时目录压缩，再把压缩包传到wwwroot目录，整个流程结束后只会生成部署manifest文件，不会做源目录和目标目录的文件哈希比对，也不会扫描目标目录的文件完整性，只要压缩包传输过程没有抛出致命错误，就会判定部署成功。
• 多实例同步延迟：如果你的Web App开了多实例扩容，部署内容到共享存储后，会异步同步到所有实例的挂载点，刚部署完的几十秒内如果请求落到还没同步完成的实例上，就会看到文件缺失、版本不对的情况，等同步完成后访问又恢复正常，看起来就像复制失败。

• 部署前后增加启停动作：在GitHub Actions的部署步骤前，通过Azure CLI执行az webapp stop命令停掉应用进程，等部署完成后再执行az webapp start启动，彻底避免运行时文件锁的问题。
• 开启包运行模式：在Web App的应用配置中添加参数WEBSITE_RUN_FROM_PACKAGE=1，开启后平台会直接把Oryx构建好的压缩包挂载为wwwroot的只读文件系统，不需要执行解压、逐文件复制的动作，从根源上规避复制过程的IO错误、文件锁冲突，部署速度也会明显提升。
• 增加部署后校验：在GitHub Actions的部署步骤后增加2-3分钟的等待+健康检查逻辑，轮询应用的核心接口确认返回正常后再结束工作流，如果碰到同步延迟、文件缺失的情况直接触发重试部署。

内容的提问来源于stack exchange，提问作者Snorre Hukkelås