问题描述
在 Azure App Service 上运行的 Web 应用可能遭遇一类棘手的问题——缓存文件无法删除、无法移动，即使重启应用也无法解除锁定。
在操作App Service的文件如果遇到以下典型症状，很可能正在经历"僵尸文件锁"：
- 缓存文件操作失败：/home/site/wwwroot 下的某个缓存文件无法删除、无法移动
- 管理工具失效：FTP 和 Kudu 控制台均无法操作该文件，mv 命令报告"文件不存在"
- 重启无效：应用重启甚至实例切换后，文件异常状态依然存在
- 随机表现：同一 URL 的请求，有时成功、有时失败
通过 stat 命令检查异常文件时，会发现关键线索：
如上图中的结果：
Links: 0 意味着文件已执行了删除（unlink）操作，但仍有进程持有该文件的句柄。文件处于一种"已删除但仍存在"的幽灵状态
Change: 2026-02-25 19:44:26 # 元数据变更时间（推测为删除操作时刻）
Birth: 2026-02-11 08:24:45 # 文件创建时间
如果一个文件的状态是正常情况，stat命令的结果如下：
正常情况下的属性解答：
File: app.py
Size: 2307 # 文件大小为2307字节
Blocks: 8 # 占用8个block
IO Block: 1048567 # IO块大小
Device: ... # 存储设备ID
Inode: ... # inode编号（文件真实身份）
Links: 1 # 硬链接数量（关键字段）
Access: (---) # 权限
Uid/Gid # 所属用户/用户组
Access/Modify/Change # 时间戳
那么，是什么情况会导致links = 0， 文件已执行了删除操作，但仍有进程持有该文件的句柄, 处于一种"已删除但仍存在"的幽灵状态呢？
问题解答
在 Linux系统中，"删除文件"并不意味着立即释放磁盘空间：
"幽灵文件"的行为特征：
这就解释了一个看似矛盾的现象：mv 命令报告"文件不存在"（因为目录项已删除），但文件数据实际上仍存在于存储中。在单机本地磁盘环境下，这种情况通常不会造成严重问题——进程退出后 fd 自动关闭，文件真正删除。但在 Azure App Service 的分布式架构下，情况完全不同。
Azure App Service 的文件系统分为两个截然不同的存储层：
- /home 是基于 Azure Files 的远程共享存储，具备持久化和多实例共享能力，但存在网络延迟且依赖远端锁机制；
- /tmp 是本地磁盘，性能高但实例私有且不持久。关键点在于文件锁由远端存储维护，与应用进程解耦。
重启 App Service 仅终止计算实例进程，并不会立即释放 SMB 会话及其文件句柄，因此可能出现“锁未释放”或“幽灵文件”等现象。
文件“锁死”根本原因：
文件存储在/home/site/wwwroot下，通过网络挂载的持久化共享存储。
当文件在发生元数据变更（如删除/修改）时，如果遭遇瞬时的网络抖动或并发冲突，存储层可能会产生一个“僵尸锁定”状态。
普通的“应用重启”仅重置了计算节点的进程，但并未切断与底层共享存储的连接会话。
由于存储层认为该文件句柄仍被“某个连接”持有，它会持续维持这个 Links: 0 的锁定状态。
即使切换了实例，新实例在挂载同一块磁盘时，依然会继承这个错误的文件系统状态。
解决办法：
无法删除被锁文件 ----> 通过复制该文件为新文件 ----> 在应用中修改引用指向新文件 ----> 重启应用后问题恢复
该方案的本质是：绕开被锁定的文件，而不是试图修复锁本身
参考资料
Understanding the Azure App Service file system : https://github.com/projectkudu/kudu/wiki/Understanding-the-Azure-App-Service-file-system