xargs -I {}报{}不存在错误 不带-I参数正常的原因排查

你遇到的是macOS系统自带的BSD版本xargs在使用-I占位符替换时的已知实现bug，和文件内容、权限、扩展属性（即ls -l显示的末尾@标识）没有任何关系。
这个bug的触发逻辑非常明确：

• 当使用-I {}参数时，xargs会走单独的占位符替换逻辑，每读入一个路径参数，就把命令行里的{}替换成实际路径再执行。
• BSD xargs的替换逻辑存在缓冲区边界处理缺陷：当读入的文件路径字符串长度刚好落在内部缓冲区的特定截断区间时，替换步骤会直接失效，不会把{}替换成实际路径，而是把字面量{}直接传给后续命令，因此才会出现wc: {}: open: No such file or directory这类报错。

你观察到的所有测试现象都完全符合这个bug的特征：

• 不带-I参数的xargs正常：因为该模式下xargs走批量拼接参数的逻辑，完全不涉及占位符替换流程，不会触发bug。
• 把wc换成ls仍然报相同错误：问题出在xargs本身的替换逻辑，和后续执行什么命令无关。
• 复制报错文件所在目录到文档根目录，错误数仍为8：复制操作没有改变这8个文件的相对路径长度，仍然满足bug触发条件。
• 同目录下复制文件生成副本，错误数变为9：新生成的副本路径长度刚好也落在触发bug的长度区间内，因此多了一个报错样本。
• 修改副本权限、内容、重命名后错误数不变：你操作后的文件路径长度仍然在触发bug的区间内；新建同内容替代文件不触发报错，是因为新文件的路径长度没有踩中边界。
• 移走报错文件错误数减1、移回错误数加1：本质是移除/加回了满足路径长度触发条件的样本。

可以通过以下操作快速验证根因：

• 给xargs加-t参数执行：该参数会让xargs在每次执行命令前，把实际构造的完整命令行打印到标准错误，你可以直接看到报错的那几次执行中，{}根本没有被替换成实际文件路径。
• 统计所有报错文件的相对路径字节长度：你会发现这些路径的长度高度集中在某个固定值附近，和文件其他属性没有相关性。
• 替换成GNU版本xargs测试：通过homebrew安装findutils包后，用GNU版的gxargs执行完全相同的命令，报错会直接消失，可直接确认是BSD xargs本身的实现问题。
• 手动构造测试样本：在任意目录下创建几个路径长度和报错文件完全一致的空txt文件，用相同的xargs命令执行，可稳定复现同样的报错，和文件内容、属性无关。

如果要规避这个问题，不需要修改文件，选以下任意一种写法即可：

• 直接使用你最开始不带-I的xargs写法，这个逻辑不仅没有bug，执行效率还远高于带-I的写法（带-I会为每个文件单独启动一次进程，不带-I会批量传参，减少进程开销）。
• 如果确实需要对每个文件单独执行命令，直接用find自带的-exec参数代替xargs，写法如下：

find . -type f -name "*.txt" -exec wc -l {} \; >| ~/Downloads/find_exec_wc.txt

• 替换为GNU版本的xargs使用，不存在该边界bug。

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