Cursor 给你生成了一段漂亮的 diff，你按 “Apply”（cmd-enter 或聊天框右上角按钮），右下角转了一下圈——然后什么都没发生。文件没改、没报错、Composer 的 status 也没变。这不是 bug 失败，而是 Cursor 的 “apply” 走的是另一次 LLM 调用（不是字面 patch），任何阻塞都会让它静默放弃。这篇拆 5 个常见根因，给出快速复活路径和”再次 reapply”的正确触发方式。
常见原因
按命中率从高到低排序。
1. Composer / Inline / Chat 模式与目标文件不匹配
Cursor 有三种 edit surface：Chat（cmd-L）建议但不直接改文件、Inline（cmd-K）只改光标处、Composer（cmd-I）跨文件改。如果在 Chat 里点 Apply，但目标文件没在编辑器打开，apply 经常静默失败。
症状：Chat 里 diff 显示完整，按 Apply，按钮变灰一秒后回弹
原因：Cursor 试图把改动 apply 到一个 detached 文件 buffer如何判断：换到 Composer 模式（cmd-I）重新粘 prompt——如果 Composer 里能 apply 就是 Chat / Inline 模式不匹配。
2. 文件被别的进程或 git 锁了
.git/index.lock、.git/HEAD.lock、运行中的 next dev / vite 文件 watcher、另一个 VS Code 窗口打开同一文件——都能让 apply 拿不到写锁。Cursor 不会弹”被锁”对话框，只是不写入。
如何判断：
ls -la .git/*.lock # 残留锁文件
lsof | grep <filename> # 谁打开了这个文件有残留 lock 或别的进程占用就是这个。
3. Cursor 扩展 / 模型 endpoint 过期
Cursor 自身更新很快（每 1-2 周一版）。旧版本的 apply 协议有时不兼容新模型；或你切了模型（比如从 sonnet-4.5 换到 opus-4.7）但本地缓存没刷新。
如何判断：
- 看
Cursor → About，版本是否落后超过 3 周 Settings → Models里换一个模型重试，行不行立刻知道- 控制台（cmd-shift-P → “Developer: Toggle Developer Tools”）看 network 报 401/403/timeout 没
4. 文件系统只读 / 权限不足
WSL 跨盘符（/mnt/c/...）、Docker 容器内挂载 read-only volume、macOS Full Disk Access 未授权 Cursor、NFS / SMB 网络盘——apply 拿不到写权限。
如何判断：
touch the-file-you-want-to-edit # 看能不能写
ls -l # 检查权限位
stat -f %Sp <file> # macOStouch 都失败就是文件系统层的问题。
5. Diff base 与磁盘内容不一致（“file changed since”）
如果 Cursor 生成 diff 的瞬间你又手动改了文件，apply 会因为 base 不匹配 silently skip。常发生于：跑了 formatter / prettier --write、git pull 改了文件、AI 在后台又生成了一版。
如何判断：Cursor 状态栏里出现 “File modified” 提示，或者 apply 后 diff 仍然完整显示不消失。
最短修复路径
按耗时从短到长。Step 1+2 能解掉 70% 的”按 Apply 没反应”。
Step 1：保存所有打开文件 + 关掉其他编辑器实例
最简单见效：
cmd-shift-S 保存全部（Code → File → Save All）
然后关掉所有其他打开同一项目的 VS Code / Cursor / Sublime 窗口跨工具同时打开同一文件是 #1 触发原因。关闭后回 Cursor 按 cmd-enter reapply。
Step 2：在 Composer / Inline / Chat 之间切，再 reapply
如果你是在 Chat 里 apply 失败：
- 选中 Chat 里的整段 diff 或回答
- cmd-shift-I 打开 Composer
- 粘贴 prompt 重新让它写
- Composer 里的 apply 走的是另一条路径，经常能过
或者直接在文件里 cmd-K (Inline) 选中要替换的代码块，让它就地改。Inline 比 Composer 比 Chat apply 成功率更高（作用范围越小，越不容易出错）。
Step 3：清理 git lock 和文件 watcher
# 清理 git 锁
rm -f .git/index.lock .git/HEAD.lock
# 看谁在占用文件
lsof | grep src/components/UserSettings.tsx
# 关掉占用进程
kill -9 <pid>
# 重启 dev server（watcher 卡死也会阻塞写）
pkill -f "next dev"
pkill -f "vite"然后 Cursor 里点聊天右上角的 “Retry” 或 cmd-enter reapply。
Step 4：升级 Cursor，换一个模型 retry
1. Cursor → Check for Updates → 重启
2. Settings → Models → 把 default model 换成另一个（如 sonnet-4.5 ↔ opus-4.7）
3. 重新让它生成 diff，apply如果换模型立刻成功，原模型的 apply 协议端可能临时挂了，到 status.cursor.com 看一眼。
Step 5：检查文件系统权限 + 用绝对路径打开项目
# 测试能不能写
touch /path/to/project/src/file.tsx && echo OK || echo "no write permission"
# macOS：System Settings → Privacy & Security → Full Disk Access → 勾上 Cursor
# Linux/WSL：
chmod -R u+w /path/to/project
# 别在 /mnt/c/... 下开项目，挪到 ~/projects/ 这种 native FSCursor 在 read-only mount 上不会报”读写权限”，只会安静地不 apply。
Step 6：还不行就 hand-apply
最后兜底：
- Cursor 聊天里选中 diff，cmd-C
- 打开目标文件，手动按 diff 改
- 用
git diff验证改动正确
不是优雅，但能立刻 unblock 你。
预防建议
- 同一文件不要多工具同时编辑（关掉其他 VS Code / Cursor 窗口）
- Cursor 开自动更新（Settings → Update → Auto）
- 把
.git/*.lock加进 cleanup 脚本，dev server 启动前自动清 - 项目不要放在 WSL
/mnt/c/...或网络盘上，用 native filesystem - 文件特别大（> 2000 行）容易 apply 失败，先用 Composer 拆成小 patch
Settings → Beta里关掉非必需的实验功能，新功能 bug 多- macOS 给 Cursor 授全盘访问，避免沙盒拦写