通过FTP推送到Azure App Service的代码未在应用中生效

按以下优先级逐一操作排查：

• 首先强制重启应用实例
  FTP上传文件不会触发Azure App Service自动重载Node进程，Node启动后会把所有加载的业务代码、依赖全缓存在进程内存里，你在磁盘上改了文件，内存里跑的还是启动时加载的旧版本。直接在Azure门户对应App Service页点顶部「重启」按钮，等实例启动完成后再测试。
  不想全量重启的话，可以进Kudu的Debug Console进入site/wwwroot目录，新建一个名为app_offline.htm的空文件，Azure检测到这个文件会自动卸载当前运行的Node进程，等5秒删掉这个文件，服务就会用磁盘上的新代码重新拉起。
• 清理构建和依赖缓存
  你只上传了改动过的文件，很容易漏了构建产物或者缓存文件：
  • 如果项目用了TypeScript、打包工具（webpack/rollup等），确认你上传的是本地编译打包后的完整产物，不是未编译的源文件；把服务端旧的dist/build等构建输出目录整个删掉，再重新上传完整的新构建产物，不要只传单个改动过的文件
  • 进入Kudu控制台，在site/wwwroot路径下执行rm -rf node_modules/.cache清除依赖缓存，如果改了package.json里的依赖版本，直接执行npm install --production重新安装全量生产依赖
  • 如果你开了App Service本地缓存（配置项WEBSITE_LOCAL_CACHE_OPTION设为Always），实例启动时会把共享存储的代码拷到实例本地磁盘运行，你FTP传的文件不会同步到本地缓存，把这个配置项关掉再重启实例即可
• 检查部署和路由配置
  • 检查App Service部署槽位配置，确认你上传代码的目录是当前承载100%流量的生产槽对应的site/wwwroot，不要误传到过渡槽
  • 进对应Azure Bot资源的配置页，确认消息终结点指向当前App Service的正确api地址，没有指向旧的测试服务或者其他部署环境
  • 检查应用配置里的WEBSITE_NODE_DEFAULT_VERSION值，和你本地开发运行的Node.js大版本保持一致，避免版本兼容导致的逻辑异常
• 清除渠道侧缓存
  如果在Azure Bot自带的Web Chat测试端已经能拿到新的返回结果，只有Microsoft Teams里还是旧结果，就是Teams侧的缓存问题：
  • 在和机器人的单聊会话里输入/clearcache强制清除当前会话的机器人缓存
  • 完全退出Teams客户端重新登录，或者在Teams管理中心重新上传机器人安装包、重新安装机器人应用，Teams对机器人响应的缓存最长可能留存24小时，等自然过期也会恢复

补充：FTP不是Azure App Service推荐的Node.js应用部署方式，后续更新建议用Zip Deploy或者对接CI/CD流水线，这类部署方式会自动触发应用重启、执行构建命令，不会出现磁盘代码更新但服务不重载的问题。

内容的提问来源于stack exchange，提问作者Rahil Kadakia