pnpm Infinity 参数报错

工作区原来用 pnpm -r --workspace-concurrency=Infinity test 并行执行测试，换了 pnpm 后却报 invalid digit found in string。脚本还没运行，CLI 就拒绝了 Infinity：先核对实际启动的 pnpm，不要先修改各个包的测试命令。

Infinity 是 --workspace-concurrency 文档中明确支持的值，表示工作区任务不设并发数量上限。正式 pnpm 12.11.2 修复了把这个值按普通数字解析而报错的缺陷。不能只凭同一句数字解析错误，就把其他参数的故障也归入这一修复。

看报错是否指向 workspace-concurrency

保留原来的命令和第一条参数错误，确认失败发生在 --workspace-concurrency，值确实是区分大小写的 Infinity。同时检查本地与 CI 实际执行的 pnpm 版本，以及 package.json、包管理器启动入口和缓存是否一致。

有些环境先运行全局启动器，再按项目的包管理器约束切换版本。只看 package.json 中的一行版本，不能证明这次解析参数的就是那一版。用同一个终端或 CI 步骤查看实际版本：

pnpm --version

版本确认后，沿项目原有安装与版本约束更新到兼容、包含修复的正式版本。已经采用 pnpm 12 的项目，可以核对 12.11.2；仍使用其他主版本的项目，不为这一条错误直接跨主版本更新整套锁文件。

随后在受控的工作区中复查原有测试命令：

pnpm -r --workspace-concurrency=Infinity test

这行会执行各包现有的 test 脚本，并非只读检查。保留原有工作区选择、任务依赖和测试环境，不拿包含业务写入的脚本临时充当排错示例。CI 镜像与包管理器缓存也要真正换成已审定版本。

临时用有限并发时，明确改变了什么

暂时不能切换版本，可以在原命令中选择适合机器资源的正整数并发数。例如：

pnpm -r --workspace-concurrency=4 test

这里的 4 只是示例，需要按测试任务的内存、CPU 和外部服务限制确定。它会把同时运行的工作区任务限制为四个，已经改变了原来的无限并发策略；不能把运行变慢或顺序变化误认为修复又失效。

0 和负数也不是 Infinity 的替代写法。它们用于按 CPU 核心数计算并发上限，有各自的规则。不要为了绕过字符串错误随意改成零，再宣称恢复了原来的并发数量。

无限并发并不保证更快。多个测试进程可能争用内存或同一个服务，CLI 接受参数后出现的资源耗尽、测试超时，应按实际任务另查。

参数能解析之后，再看任务结果

恢复标准是原来的工作区选择得到执行，各测试任务按预期完成并返回正确结果。仅有 pnpm --version 显示新版本，或者命令不再报 invalid digit，还不足以证明测试通过。

若已有 12.11.2 却仍在同一参数上报错，核对实际二进制路径、启动器、脚本中是否又调用了另一份 pnpm，以及错误对应的完整命令。需要撤回版本调整时，一起恢复审定的包管理器约束和相关锁文件变更；临时并发值也应明确保留或恢复，不让两套任务策略混在 CI 中。