根本原因是文件属主错位，如sudo误操作或web服务器以root身份写入，导致当前用户无权修改；需先用chown修复所有权，再酌情chmod调整权限。
文件带小锁图标、右下角显示 read-only，根本原因不是 Git 或 PhpStorm
90% 的情况是文件属主错位——比如 git stash 时误用了 sudo，或 Web 服务器（如 nginx、php-fpm）以 root 或 www-data 身份写入了文件，导致当前用户无权修改。PhpStorm 只是忠实地反映了系统级权限状态，它本身没“锁”你。
验证方式很简单：终端进项目目录，执行 ls -l path/to/file.php。看输出第三列（所有者）是不是你的用户名；再看第一列权限位，比如 -rw-r--r-- 表示用户可读写，但若所有者是 root，哪怕权限是 644，你也写不了。
Linux/macOS 下必须先 chown，再考虑 chmod
chmod 单独用基本无效——属主不对，改权限等于白改。核心动作是把所有权还给你自己：
- 查当前用户名：
whoami - 递归修复整个项目（推荐）：
sudo chown -R $(whoami):$(id -gn) /path/to/project（macOS 用staff替代$(id -gn)） - 只修单个文件：
sudo chown $(whoami):staff file.php（macOS）或sudo chown $(whoami):$(whoami) file.php（Linux）
之后补一句 find . -name "*.php" -exec chmod 644 {} \; 确保 PHP 文件权限合理；目录用 chmod 755，别碰 777——Web 服务器若与你同用户运行，等于裸奔。
WSL2 环境下额外要配 /etc/wsl.conf
WSL2 默认挂载 Windows 文件系统时不保留 Linux 权限元数据，chown 和 chmod 在 /mnt/c/ 下基本失效。必须在 WSL2 里编辑 /etc/wsl.conf，加上：
[automount] enabled = true options = "metadata,uid=1000,gid=1000,umask=22,fmask=11"
然后关掉 WSL：wsl --shutdown，重启终端再进项目目录。否则你看到的 “已修复” 只是假象——文件实际仍被 Windows 权限机制锁定。
属主和权限都对，还是只读？查进程占用和 PhpStorm 缓存
如果 ls -l 显示属主是你、权限也正常，但 PhpStorm 依然报只读，说明有外部锁定：
- 用
lsof +D /path/to/project查是否有php-fpm、nginx、node进程正占用该文件；找到 PID 后kill -9 PID - Docker volume 场景下，宿主机
chown了，但容器内 UID 不匹配——得在docker run加-u $(id -u):$(id -g)或调整docker-compose.yml的user字段 - PhpStorm 自身缓存出错：菜单栏 File → Invalidate Caches and Restart… → Invalidate and Restart
真正麻烦的是混合场景：比如 WSL2 + Docker + nginx 写日志 + PhpStorm 打开日志文件——这时候光改属主不够，得一层层确认 UID 映射、挂载选项、进程状态，漏一环就卡住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
