在 Windows 上用chmod本身就是一件拧巴的事。很多从 Linux 或 macOS 切过来的开发者或者偶尔要在 Windows 上写 Shell 脚本、跑 Python 部署脚本的人都会遇到这样的报错chmod 不是内部或外部命令也不是可运行的程序或批处理文件。或者更隐蔽一点脚本不报错但是chmod静默失败文件权限根本没变。这种问题一旦出现在生产环境发布流程里轻则部署失败重则改坏文件属性导致服务拒绝启动。这篇文章想解决的不只是“Windows 上没有 chmod 怎么办”这种基础问题而是帮你梳理清楚Windows 、chmod 和文件权限这几个概念之间到底什么关系想让 chmod 在 Windows 上“能用”有哪几条靠谱的路每条路的原理、坑和适用场景分别是什么我会按自己实际排查和修复的路径从最土的办法讲到接近 Linux 原生体验的方案最后再给出一套适合放进自动化脚本的落地做法。1. 为什么 Windows 上会出现“chmod 不能用”这个 bug先说一个判断Windows 上“不能使用 chmod”本质上不是 chmod 这个工具缺失而是 Windows 文件权限模型和 Unix 文件权限模型根本不是一回事。Unix/Linux 的文件权限是 POSIX 权限模型用 9 个比特位表示 owner / group / others 的 rwx 权限一个普通用户可以通过chmod直接修改自己文件的三组权限位。Windows 则使用 NTFS ACL访问控制列表模型权限由 ACL 条目组合而成通常要通过“安全属性 → 编辑权限”或icacls命令来修改。两者在概念设计上就不能直接对应。所以当你把 Linux 的部署脚本拷到 Windows 上运行脚本里的chmod x自然就找不到命令。而某些 Git 自带的模拟环境比如 Git Bash之所以能用chmod是因为它自己实现了一层 POSIX 权限和 Windows 文件属性的转换。但这层转换并不完全可靠特别是在跨磁盘、跨文件系统、启用了 Windows 安全策略的场景下会出现“chmod 执行成功但权限没生效”的诡异现象。从使用者的视角看这确实就像一个 bug。我为什么要专门写这篇是因为最近在帮同事排查一个 Windows 上运行 Python 部署脚本失败的问题脚本执行到chmod 755时直接报错而脚本是从 Linux 服务器直接拷贝过来的。排查过程中发现很多人对 Windows 上 chmod 的可行方案理解非常混乱有人建议装 Cygwin有人建议用 PowerShell 直接改 ACL有人干脆手动改属性。其实每种方案都有它的适用边界用错了反而会产生新问题。读完这篇文章你会得到几条经过验证的解决路径以及每条路径背后的原理和限制不再需要看到chmod报错就手足无措。2. 核心概念chmod、Windows 权限与“可用”的几种定义2.1 chmod 到底在做什么chmod是 Unix/Linux 下改变文件模式位的命令。模式位中最常见的是三类权限r读权限数值为 4w写权限数值为 2x执行权限数值为 1比如chmod 755表示“文件所有者可读可写可执行用户组和其他用户可读可执行”。在 Unix 系统中执行权限意味着这个文件可以被操作系统当作程序来运行。注意“执行权限”和“文件内容可执行”不是一回事执行权限只是一个标记位系统在加载文件时会检查它。2.2 Windows 文件权限模型与“只读 / 执行”的差异Windows 的 NTFS 权限粒度要细得多包括“读取”“写入”“读取和执行”“修改”“完全控制”等高级权限并且可以针对单个用户或用户组单独配置。从用户日常感知看Windows 文件属性只有“只读”“隐藏”等简单勾选并不暴露一个直观的“执行”位。更关键的一点是Windows 判断一个文件能否被执行并不是看文件属性里的某个 bit而是看文件扩展名和关联程序。例如.exe、.bat、.cmd等扩展名会被系统直接当作可执行程序而.sh脚本在 Windows 上没有默认可执行的概念。这就是为什么你在 Windows 上双击一个 Linux 的.sh脚本系统只会问你“用什么程序打开”而不是把它当作程序运行。2.3 在 Windows 上“chmod 能用”有哪几种理解命令存在shell 里能够输入chmod不会提示“不是内部或外部命令”。语法兼容chmod 755 file能执行成功不报错。权限真实生效执行chmod x后脚本能直接被相应解释器读取并运行或者后续的部署工具能感知到这个权限变化。跨环境一致同一份脚本在 Windows 和 Linux 上运行结果一致。很多人遇到的“bug”其实停留在第一、二层觉得命令存在、不报错就完事了。但真正要保证部署脚本可靠必须让第三、四层也成立。3. 环境准备先搞清楚自己处在哪个“Windows”要修复这个 bug第一步不是安装工具而是先弄清楚自己的 Windows 环境属于哪一类。因为不同环境下的解决方案完全不同。常见的 Windows 开发环境包括原生 Windows CMD / PowerShell系统自带的终端环境不经过任何 Unix 模拟层。Git Bash / MSYS2Git for Windows 自带的 bash 环境实现了部分 POSIX 兼容层。Windows Subsystem for LinuxWSL运行在 Windows 上的 Linux 子系统是一个轻量虚拟机或系统调用翻译层可以直接运行 Linux 镜像。Cygwin老牌的 Windows 下的 Unix 模拟环境。Docker DesktopWindows 容器或 Linux 容器容器内的 Linux 环境天然支持 chmod但容器与宿主机文件交互时权限映射很关键。不同环境下“修复 chmod”的路径不一样。文章后面会按环境分别给出方案。但先提醒一下不要在不了解当前终端类型的时候盲目安装 Cygwin 或修改环境变量很容易把系统 PATH 弄乱。3.1 快速判断当前环境在终端输入下面命令观察输出echo $0如果输出是-bash或-sh说明你在 bash 类环境可能是 Git Bash、MSYS2 或 WSL。如果输出是空、cmd或powershell说明你在原生命令行环境。Get-Command chmod -ErrorAction SilentlyContinue如果Get-Command有输出说明 chmod 当前是可达的如果没有任何输出说明当前环境中没有该命令。3.2 查看 Windows 版本和文件系统类型NTFS 和 FAT32 对权限的处理差异很大。FAT32 文件系统不存储 ACL 权限任何 chmod 或 icacls 在这种 U 盘、老磁盘上都不会生效。Get-Volume | Select-Object DriveLetter, FileSystemType, HealthStatus只有NTFS或 ReFS卷上的文件Windows 层面的 ACL 才可能完整生效如果看到FAT32或exFAT那么基于权限的方案基本不可行只能换文件系统或换思路。4. 方案一不用 chmod用 Windows 原生方式执行脚本最稳如果你的核心诉求是“让一个脚本能跑起来”那么最简单、最稳定的方式是忘掉 chmod直接使用 Windows 原生的脚本调用方式。4.1 对于 Python 脚本在 Windows 命令行下Python 脚本本身不需要“执行权限”。只要安装了 Python并正确配置了环境变量就可以直接用python命令运行脚本python deploy.py如果你需要在 PowerShell 下运行等价用法是python .\deploy.py这完全绕开了 chmod。很多从 Linux 迁移过来的部署脚本其实只是python xxx.py的包装把chmod x xxx.py那一步删掉在 Windows 上直接调用解释器即可。4.2 对于 Shell 脚本原汁原味的.sh脚本在 Windows 上没法直接运行。如果你不能重写为.bat或.ps1那么至少有两个选择在 Git Bash 中运行bash script.sh此时不依赖文件的可执行位脚本中的 chmod 可能仍然会报错。在 WSL 中运行bash script.sh这是最接近 Linux 环境的方式。4.3 对于 bat / cmd 脚本Windows 原生的批处理文件.bat/.cmd不需要 chmod双击或直接调用即可deploy.bat因此“修复 chmod 不能使用”的第一条建议是重新审视脚本能把权限位依赖去掉就去掉特别是在 Windows 原生环境里。这个方案解决的是“脚本能不能跑”的问题但不是真正让 chmod 命令可用。如果脚本里大量使用了chmod、chown、ln -s等命令逐个删改不现实那就需要方案二或方案三。5. 方案二把 Git Bash / MSYS2 里的 chmod 调教到“能用”很多 Windows 开发者安装了 Git for Windows自动获得了一个 Git Bash。Git Bash 带了不少 Unix 常用工具其中就包括 chmod。但是轻率使用你会发现两个 bug 级问题在项目目录下执行chmod x deploy.sh没有任何报错但是把这个脚本拿到 WSL 或 Linux 服务器上却发现它的权限还是 644可执行位完全没保住。这背后其实是 Git Bash 的权限映射逻辑Git Bash 里的chmod由 MSYS2 运行时提供它会把 Unix 权限中的“只读”映射到 Windows 的只读属性而“可执行位”则通过文件扩展名或特定 ACL 规则来模拟。当目标文件在 NTFS 卷上时MSYS2 通常能更新 ACL但如果文件所在卷是共享目录、虚拟磁盘或某些网络文件系统MSYS2 可能无法写入权限信息这时 chmod 就会“假装成功”。5.1 检查 Git Bash 中的 chmod 是否真正生效在 Git Bash 中执行touch test.sh chmod x test.sh ls -l test.sh如果输出中的修改时间后有x标志例如-rwxr-xr-x 1 user 197609 0 Feb 20 10:10 test.sh说明 MSYS2 已经在本机 ACL 中写入了可执行位。这时如果脚本在 Git Bash 里能被直接执行就属于“真实生效”。如果ls -l显示的还是-rw-r--r--说明 chmod 被忽略了。5.2 让 chmod 跟随文件复制到 Linux 后依旧有效如果项目文件需要同时在 WindowsGit Bash和 Linux 上使用而且必须保留可执行位建议在 Git Bash 中执行完 chmod 后再用git提交时会遇到一个问题git 默认会在提交时强制执行core.fileMode的规则。如果 Windows 上的文件模式和索引不一致git status会频繁提示权限变化。一个常见做法是在 Windows 仓库中设置git config core.fileMode false但这样会让 Git 忽略所有可执行位的差异导致 Linux 上git checkout后文件没有执行权限。比较科学的做法是在 Linux 上保留core.fileMode true在 Windows 上设置core.fileMode false而不是全局修改。如果你要临时生成一个带执行位的 tar 包MSYS2 的 tar 会尝试保留权限。但到底保不保留取决于 MSYS2 是否成功写入了 ACL。5.3 改进方法在 Git Bash 中强制为脚本添加可执行位有时候 MSYS2 的默认逻辑因为acl相关配置不完整导致 chmod 失败。可以检查一下msys2的挂载选项。执行mount输出中会显示/c等挂载路径的选项。如果看不到acl字样可以尝试在 MSYS2 安装目录下编辑/etc/fstab给根路径添加acl选项或者在挂载时手动指定mount -o remount,acl /c但这样的修改在重启 Git Bash 后可能失效需要写入配置文件。从实践看绝大多数 Git for Windows 默认已经启用 acl遇到 chmod 不生效通常是文件系统类型或网络路径问题。综合判断如果只是临时在 Windows 上调试脚本Git Bash 的 chmod 基本够用如果想作为长期项目环境更推荐 WSL。6. 方案三真正从根上解决用 WSL 获得原生 Linux chmod如果你需要的不是“一个名义上的 chmod”而是真实可靠的 POSIX 权限语义那么 Windows 上最接近的答案就是启用 WSLWindows Subsystem for Linux。WSL 1 通过系统调用翻译层把 Linux 系统调用变成 Windows NT 内核调用文件权限会映射到 Windows ACL 上。WSL 2 使用轻量虚拟机运行完整 Linux 内核文件系统有自己的 metadata 支持chmod在 WSL 内部对 Linux 文件系统如 ext4的语义和真实 Linux 完全一致。6.1 安装 WSL简短版以 Windows 11 或较新的 Windows 10 为例以管理员身份打开 PowerShell执行wsl --install该命令会安装 WSL、虚拟机平台和默认的 Ubuntu 发行版。安装完成后需要重启电脑。重启后进入 Ubuntu 终端就可以直接使用chmod。如果系统已经安装过 WSL可以查看当前状态wsl --status6.2 在 WSL 中修复 chmod bug假设你有一个deploy.sh放在 Windows 的D:\project目录从 WSL 访问这个目录的路径是/mnt/d/project。在这个目录下可以执行cd /mnt/d/project chmod x deploy.sh注意WSL 对/mnt/c、/mnt/d这种 Windows 挂载点的文件权限仍然是通过 metadata 映射实现的默认情况下chmod可能被忽略。因为 WSL 挂载 Windows 磁盘时默认没有启用 metadata 选项。如果想在/mnt/d目录下让 chmod 真正改变 NTFS ACL 中的可执行位需要修改/etc/wsl.conf[automount] enabled true options metadata,umask022然后在 PowerShell 中重启 WSLwsl --shutdown重新进入 WSL 后再到/mnt/d/project下执行chmod x deploy.sh此时ls -l会显示可执行位同时 Windows Explorer 中该文件的 ACL 也会增加相应的权限。这是目前 Windows 上能稳定使用 chmod 行为的最佳方式尤其适合开发、测试和部署脚本需要跨系统保持一致性的场景。6.3 WSL 与 Windows 文件交互的权限映射坑使用 WSL 时有三个常见坑/mnt/c默认没有 metadata未配置 wsl.conf 之前chmod会失败或无效。Windows 文件上的 ACL 与 Linux 权限不完全等价WSL 映射时经常出现ls -l显示 777但实际 Windows 权限非常严格或非常宽松的情况注意不要把它当成真实 Linux 权限来审计。跨文件系统操作慢从 WSL 访问/mnt/c的文件每次文件操作都要经过翻译层大量find、chmod会很慢。如果项目文件很多建议先把文件复制到 WSL 的 Linux 根文件系统如~/project下操作最后再复制回 Windows 侧。7. 方案四用 PowerShell 和 icacls 替代 chmod适用于 Windows 原生环境如果你是公司 Windows 服务器管理员不能安装 WSL也不能用 Git Bash就需要用 Windows 原生命令来模拟 chmod 的关键效果。7.1 chmod 常见的三种权限操作对应到 icacls在 Windows 上文件权限操作的主要命令是icacls。先看映射关系chmod x file给文件添加“执行”权限。对应 NTFS 权限是让用户/组拥有“读取和执行”。chmod -x file撤销执行权限。对应 NTFS 权限是移除“读取和执行”。chmod 600 file所有者可读写其他用户无权限。对应设置“所有权者完全控制其他用户完全拒绝或移除”。7.2 用 PowerShell 给当前用户添加执行权限假设我们想给脚本deploy.ps1的当前用户添加读取和执行权限可以用$user [System.Security.Principal.WindowsIdentity]::GetCurrent().Name $acl Get-Acl .\deploy.ps1 $permission $user, ReadAndExecute, Allow $accessRule New-Object System.Security.AccessControl.FileSystemAccessRule($permission) $acl.SetAccessRule($accessRule) Set-Acl .\deploy.ps1 $acl但这个操作本身比chmod复杂很多。更简单的方式是使用icacls命令icacls deploy.ps1 /grant %USERNAME%:RX该命令为当前用户添加“读取和执行”权限。如果希望只给当前用户完全控制可以用icacls deploy.ps1 /grant %USERNAME%:F。7.3 用 icacls 模拟 chmod 600设当前用户为domain\user目标文件为secret.txt我们希望其他用户没有任何访问权限可以分两步icacls secret.txt /inheritance:r icacls secret.txt /grant:r %USERNAME%:F第一条命令移除所有继承权限第二条命令只给当前用户完全控制。执行后其他用户和组在该文件上的访问都会被拒绝。7.4 为什么 PowerShell 方案不如 chmod 直观因为这个方案解决的是“Windows 文件系统上真正的访问控制”而不是 Linux 权限位的模拟。脚本中可能还包含chmod 644、chmod 755这样的指令全部翻译为 icacls 非常繁琐而且容易出错。如果只是想让某个脚本可执行建议优先考虑前几种方案PowerShell 方案更适合在 Windows 原生环境下做精确的 ACL 管理。8. 完整实操案例从“chmod 报错”到“脚本正常部署”这里用一个完整场景串起上述方案。假设有一个 Linux 服务器上的部署脚本deploy.sh内容如下#!/bin/bash # 部署应用 chmod x app.jar java -jar app.jar --spring.profiles.activeprod这段脚本在 Linux 上跑没问题。现在我们要在 Windows 开发机上模拟这套部署流程且暂时没有 Linux 服务器。8.1 案例目标能在 Windows 上成功执行deploy.sh中的逻辑。不希望大幅修改脚本内容。尽量让权限行为一致。8.2 使用 WSL 执行推荐方案安装 WSL并配置/etc/wsl.conf启用 metadata。将deploy.sh和app.jar复制到 WSL 文件系统的~/deploy/目录。执行cd ~/deploy chmod x deploy.sh ./deploy.sh脚本中的chmod x app.jar会正常执行。java命令也会使用 WSL 里的 JDK。这与 Linux 服务器上的行为几乎一致且不需要修改任何代码。8.3 使用 Git Bash 执行安装 Git for Windows进入项目目录。用sh deploy.sh而不是./deploy.sh来运行因为 Git Bash 的默认文件执行逻辑对./的权限检查时有时会出问题。脚本里的chmod命令可以执行但只影响 MSYS2 模拟层下的 ACL。如果验证失败可以改用 WSL。8.4 使用 PowerShell 执行如果只能使用原生终端也不允许安装 WSL那么改造脚本将deploy.sh的核心逻辑改为 PowerShell 脚本deploy.ps1# 部署应用 Write-Host Starting application... # 在 Windows 上不需要给 jar 添加执行权限直接用 java 命令 java -jar app.jar --spring.profiles.activeprod运行.\deploy.ps1如果需要保留原有 Shell 脚本也可以在 PowerShell 中调用 Git Bash 的 sh C:\Program Files\Git\bin\bash.exe deploy.sh但这是把脚本问题甩给了 Git Bash和 8.2 逻辑一致。8.5 三种方式对比方案是否能执行原生 chmod权限真实性修改脚本成本适用场景原生 PowerShell否Windows ACL高Windows 原生服务器环境Git Bash是带兼容层部分中已安装 Git 的 Windows 开发机WSL是原生 Linux完整低需要同步 Linux 部署行为的开发环境9. 运行结果与效果验证不管用哪种方案都需要验证最终效果避免“chmod 不报错但是权限没变”的坑。9.1 验证 chmod 命令是否可用在目标终端中输入type chmod如果在 Git Bash 或 WSL 中输出会显示 chmod 的路径和类型如果在 CMD 或 PowerShell 中可能提示不是内部或外部命令。9.2 验证 chmod 对文件权限的真实影响在 Git Bash 中touch test.sh chmod 755 test.sh ls -l test.sh预期输出-rwxr-xr-x 1 user 197609 0 ... test.sh如果权限位中出现r-x说明已生效。在 WSL已配置 metadata中同样执行以上命令可以看到类似的权限输出。同时在 Windows Explorer 中右键文件查看安全属性可能会看到新的权限规则。如果看不到说明 metadata 没有生效需要检查/etc/wsl.conf和 WSL 重启。9.3 验证脚本能否被执行在 WSL 或 Git Bash 中./test.sh如果文件内容有echo Hello正常输出 Hello 则说明可执行位真实生效。如果被提示 “Permission denied”说明chmod x并没有生效优先排查文件系统类型和挂载选项。9.4 验证在 Windows 原生命令中的应用如果用了 icacls 给脚本添加了“读取和执行”在 PowerShell 中可以执行icacls deploy.ps1输出中如果出现当前用户带有RX或F的权限说明权限授予成功。10. 常见问题与排查思路问题现象可能原因排查方式解决方案在 CMD / PowerShell 中输入 chmod 提示“不是内部或外部命令”原生环境没有 chmod 命令检查终端类型使用 Git Bash / WSL或改用 icaclsGit Bash 中 chmod 成功但 ls -l 显示权限没变文件所在卷不支持 ACL 或 MSYS2 配置缺少 acl执行mount查看挂载选项尝试在/etc/fstab启用 acl将文件复制到 NTFS 本机盘或启用强制挂载 acl 选项WSL 中/mnt/c下 chmod 失败挂载默认未启用 metadata查看/etc/wsl.conf中 automount 段落添加optionsmetadata,umask022后wsl --shutdown重启脚本在 Git Bash 中 chmod 后提交到 Git 后 Linux 上文件没可执行位git 的 core.fileMode 在两边不一致git config --get core.fileMode分别检查Linux 上保持 trueWindows 上设置 falseWindows 上双击.sh脚本无法运行Windows 不识别 Unix 可执行脚本检查文件扩展名关联使用 bash 解释器或 WSLFAT32 / exFAT 盘上 chmod 和 icacls 都不生效文件系统不支持 NTFS ACL使用Get-Volume查看文件系统类型将文件复制到 NTFS 分区或避免在该盘上做权限操作chmod x后脚本仍然 Permission denied文件系统挂载问题或脚本解释器没有读取权限ls -l确认读权限存在用shellcheck检查脚本为脚本所有者添加读权限检查父目录是否有执行权限icacls 设置过多导致用户无法访问文件权限继承被禁用规则过严icacls file查看当前规则使用icacls file /reset清除自定义规则后重新授权11. 最佳实践与工程建议在前面的方案之外从工程视角看还有几个更根本的习惯可以避免被 chmod 这类问题反复折磨。11.1 脚本文件尽量不依赖可执行位在团队协作中尤其是跨平台的部署脚本最好统一通过解释器调用的方式执行。Python 脚本直接写python script.py在文档里明确说明如何执行。Shell 脚本在 Windows 上用bash script.sh在 Linux 上用./script.sh或bash script.sh均可。如果使用 Makefile注意 target 命令中的 chmod 是给 Linux 环境用的Windows 下建议使用 PowerShell 脚本替代。这样的好处是脚本本身不需要设置可执行位也能运行减少了跨平台时的第一层障碍。11.2 配置统一的 git 文件模式策略如果你的项目仓库需要同时被 Windows 和 Linux 开发者修改建议编辑.gitattributes来明确哪些文件应该以可执行文件处理*.sh text eollf *.py text eollf Makefile text eollf对于纯文本脚本eollf 能避免 CRLF 导致的各种诡异报错。但如果某个.sh文件需要可执行权限*.sh 本身并不代表可执行Git 的可执行位是通过文件系统中的 chmod 位决定的。在 Windows 上设置 chmod提交到 Git 的 index 里后Git 会记录这个可执行位。如果 Windows 侧 core.fileMode 为 true那么本地文件系统权限变化会反映到 Git 状态。此时要注意Windows 上不要频繁修改 chmod否则会让 git status 显得杂乱。11.3 生产环境部署避免依赖本机权限语义如果你的部署流程是“先在 Windows 上打好包再上传到 Linux 服务器”请不要依赖 Windows 上 chmod 的效果。合理做法是在打包阶段将脚本文件置入 tar/zip 包但不依赖压缩包权限。在 Linux 服务器上部署脚本先执行chmod x或chown来设置正确的文件和目录权限。也就是说把权限设置的责任放在目标操作系统上而不是在 Windows 上强行模拟。这能避免“Windows 上看着没问题传到 Linux 上就丢了权限”的经典坑。11.4 使用 Docker 或容器作为跨平台开发环境如果项目本身已经容器化那么可以在 Windows 上安装 Docker Desktop 并运行 Linux 容器。容器内是一个完整的 Linux 环境chmod行为与服务器一致docker run --rm -v /d/project:/app -w /app ubuntu bash -c chmod x deploy.sh ./deploy.sh这种方式的优点是隔离完整缺点是 Docker Desktop 运行时资源占用较高而且 Windows 文件挂载进容器的性能有明显损耗。它更适合作为校验工具而不是日常开发首选。11.5 在脚本中做好幂等处理即使你已经选定了 Git Bash 或 WSL也建议在脚本中做好“权限不敏感”的处理。例如# 尝试设置可执行位失败也不中断 chmod x $SCRIPT 2/dev/null || true在 CI/CD 场景中这种写法可以避免因为权限问题导致流水线失败。但注意这只是容错不是根治。12. 总结与后续学习方向Windows 上“不能使用 chmod”表面看是命令缺失实际是两套权限模型之间的鸿沟。本文从这个问题出发给出了三条完整的解决路径最省事直接用 Windows 原生的解释器执行脚本跳过 chmod。最靠谱使用 WSL配置 metadata 挂载后获得接近原生的 chmod 语义。最原生使用 icacls 和 PowerShell 精确管理 NTFS 权限适合 Windows 服务器环境。如果日常开发已经安装了 Git Bash可以先用 Git Bash 应急如果项目涉及跨 Linux 部署建议优先 WSL并把权限设置在目标系统上完成。下次再看到chmod 不是内部或外部命令你可以根据当前终端环境选择最合适的处理方式而不是再浪费时间重新安装工具或手动修改文件属性。想继续深入的话可以研究 WSL 中的/etc/wsl.conf各个参数的细节以及 MSYS2 的挂载选项如何影响文件权限也可以了解一下 Windows 上运行 Shell 脚本时 CRLF 和 LF 的边界问题这些在实际跨平台项目中都很容易引发“暗坑”。把这几个点吃透Windows 上的 Unix 工具链就不再是玄学了。