我的LONGER报错清单：从pnpm到Windows路径的废弃配置迁移指南

1. LONGER 这个提醒里藏着一整年的技术债清单最近我把手头的报错日志和网上搜索热词翻了一遍发现一个挺有意思的巧合程序员每天遇到的高频问题一半都和longer这个词绑在一起。有的说某些东西no longer available——被官方废弃了有的说某操作take longer than expected——性能异常了还有的是 Windows 路径在 260 个字符上卡脖子。表面上是不同领域、不同工具的独立故障其实底层逻辑是同一个技术生态一直在往前走而你的项目、配置、客户端、路径结构还停留在过去的某个版本里。这篇文章不打算聊某个具体框架的某个具体 bug而是把我近期处理过的一组LONGER相关报错完整梳理一遍。包括 pnpm 配置迁移、PHP 指令移除、Windows 长路径限制、第三方客户端的 API 过期、AI 编辑器启动异常。每个问题我都会按实际排查链路写不只是贴一个答案而是把当时是怎么一步步定位到这个原因的讲清楚。如果你是做前端工程化、PHP 老项目维护、Windows 开发环境配置或者经常折腾 Cursor 这类 AI 编辑器的这篇文章应该能帮你省下不少试错时间。2. pnpm 报错背后package.json 里的 pnpm.overrides 为什么不生效了先说我最近碰到的一个很平静但阴险的警告。执行pnpm dev的时候终端里滚出一行warn The pnpm field in package.json is no longer read by pnpm. The following keys were ignored: pnpm.overrides. See https://pnpm.io/settings for the new home of each setting.这行警告满脸写着小问题但它对应的实际问题一点都不小我们的依赖覆盖规则直接失效了。因为某个安全漏洞团队之前把某个传递依赖强制锁定到了修复版本配置写的是{ pnpm: { overrides: { minimist: ^1.2.8 } } }结果新版 pnpm 根本不认这个字段overrides 全部被忽略依赖解析瞬间回到了裸奔状态。2.1 为什么 pnpm 要把配置从 package.json 里挪走很多人看到这个变化第一反应是pnpm 又抽风了。其实它有自己的考虑。当前前端工程化的趋势是 monorepo一个仓库里可能有十几个包每个包里都有一份 package.json。如果把 pnpm 的配置继续留在 package.json 里就会出现一个问题到底以哪个包的配置为准根目录还是子包的容易混乱。新版 pnpm 选择把配置统一收到pnpm-workspace.yaml里。这个文件应该放在仓库根目录它的设计初衷是专门给 workspace 用的配置文件把配置集中到一个地方不管仓库里有多少个子项目pnpm 只认根目录这份。2.2 迁移的具体操作我的迁移步骤是这样的先确认 pnpm 版本。如果用的是 pnpm 8 之前的版本可能还不会有这个警告到 pnpm 9、10 之后这个 warning 基本就是标配了。可以先跑pnpm -v看一眼。在仓库根目录创建pnpm-workspace.yaml。注意即使你当前没有用 workspace也要建这个文件因为新版 pnpm 把配置集中到这里了。把 package.json 里的配置段整体迁移过去。比如之前是{ pnpm: { overrides: { minimist: ^1.2.8, lodash4.17.20: lodash4.17.21 } } }迁移后就是overrides: minimist: ^1.2.8 lodash4.17.20: lodash4.17.21删掉 package.json 里原来的pnpm字段。然后重新跑pnpm install让锁文件重新生成。验证配置到底生效没有不要只看终端不再报警告还要实际确认依赖版本。可以运行pnpm list minimist --depth看看实际安装的版本号是不是你期望的。2.3 迁移里容易踩的三个坑第一个坑只删了 overrides忘了还有packageExtensions、neverBuiltDependencies、onlyBuiltDependencies这些字段。新版 pnpm 统一要求把这类配置也搬进pnpm-workspace.yaml。如果你之前配了环境字段漏掉的话有些原生依赖的 postinstall 脚本行为会变。第二个坑CI 流水线里可能有人用脚本直接改 package.json 里的 pnpm 配置。比如发布前自动往pnpm.overrides里塞东西的自动化脚本改完后可是完全没用。我这次排查最后发现团队里有个旧脚本就是干这个的幸好日志把这行 warning 留了下来不然上线后质量门禁全绿实际上漏洞依赖还是坏的。第三个坑如果你用的是 monorepo 且子包自己也有pnpm字段那就要注意搬迁的时候要从各个子包往根目录汇总。去重之后保留一份避免子包里的配置互相覆盖。最后一个建议pnpm config list这个命令在排查配置问题上很好用能看到最终生效的配置是拼出来的一份。遇到配置明明改了却不生效的怪事第一件事就是跑它看当前 pnpm 认为的有效配置是什么比翻文件快得多。3. PHP fatal errortrack_errors 指令在 PHP 8 里彻底消失了另一个高频热搜是 PHP 环境启动时报错完整一点的版本是这样的Fatal error: directive track_errors is no longer available in PHP in Unknown on line 0很多老项目维护者一定眼熟。track_errors是 PHP 早期的一个配置指令它的作用是当一个变量访问不存在的 key 或发生错误时把错误描述写进全局变量$php_errormsg。在 PHP 5.x 年代不少框架和项目靠它在业务代码里立即拿到最后一条错误信息实现简单的异常捕获。3.1 为什么 PHP 要移除它这个机制的问题很多。它依赖全局变量在并发和高负载场景下错误信息很容易被覆盖不同请求之间互相串数据。而且现代 PHP 已经提供了更可靠的错误处理方案ErrorException、error_get_last()、自定义错误处理器set_error_handler()。老机制又慢又不安全PHP 团队先是在 PHP 7.2 里把它标记为 deprecated然后直接从 PHP 8.0 开始把指令移除。也就是说PHP 8 的 php.ini 或 .user.ini 里如果再写一行track_errors On解析阶段就会直接抛 fatal error整个进程起不来。3.2 从哪一行配置引起的排查遇到这类 fatal error注意它在 in Unknown on line 0 的位置不要真的以为这是 Unknown 文件的问题。它是在 php.ini 扫描阶段报出来的只是说“配置指令校验失败”错误行号没有实际意义。排查链路通常是这样先看加载的是哪份 php.iniphp --ini会列出加载的配置文件路径。在 php.ini 里搜索track_errors找到那一行直接注释或删除。用php -v验证是否回归正常。还要注意有些虚拟主机面板会把配置放到.user.ini或 PHP-FPM 的pool.d/里搜索范围要覆盖这几处。表面上这是删除一行配置就完事的问题但这篇文章里更值得关注的是那句话背后的升级信号如果你还在用track_errors配合$php_errormsg处理业务错误这次降级只是把配置报错先暴露出来代码里真正的隐患还没有爆。老代码升级到 PHP 8 之后业务逻辑里如果有类似if (isset($php_errormsg)) { // do something }这段代码在 PHP 8 里会静默失效不会报错但也不会走你想要的逻辑。这块排查起来比配置问题隐蔽得多建议全局搜索php_errormsg把代码改成使用set_error_handler或error_get_last()。3.3 顺手收尾升级老项目时怎么快速排查指令兼容性升级 PHP 大版本最痛苦的就是这类配置项被移除的问题。这里分享一个实用命令php -n启动时不带任何配置如果它能正常启动说明问题百分百出在某份 ini 配置里如果连-n都报错才是二进制本身有问题。然后可以用二分法逐个排除自定义 ini 目录下的文件比如PHP_INI_SCAN_DIR指向的文件夹。如果你维护的不是一个项目而是一整套服务器配置建议在跑完php -v之后把所有可能配置了旧指令的文件都过一遍 grep。不光是track_errors常见的废弃指令还有allow_url_include、magic_quotes_gpc等提前清理能让后续升级省不少心。4. Windows 260 字符路径墙TP-Link 配置工具和 node_modules 都逃不过第三个longer问题更贴近 Windows 开发者的日常。很多工具报错时显示类似的英文提示allow paths longer than 260 charact再补全一点是Windows and is not configured to allow paths longer than 260 characters。这其实不是某个软件自己生成的报错而是 Windows 系统在 Win32 API 层面的限制。4.1 为什么会有 260 字符这个魔数Windows 内核在很长一段时间里路径相关的 API 使用了一个叫MAX_PATH的常量值就是 260。这是当年为了兼容性定下的规矩一个完整路径包括盘符、反斜杠、目录名、文件名、结尾的空字符不能超过 260 个字符。按理说 Windows 10 1607 之后已经支持通过注册表打开长路径但是这里有一个关键细节光是系统支持还不够运行中的应用程序必须在自己的 manifest 里声明longPathAware属性否则 Win32 API 默认还是不认长路径。所以你会看到一种很奇怪的现象同一个系统PowerShell 可以进很深的目录但老旧的 TP-Link 路由器配置工具、某些压缩软件、旧版构建工具就会直接报错。这不是系统设置没生效而是那些老程序压根没声明自己支持长路径。4.2 手动开启长路径支持的完整配置如果你需要为支持的软件打开长路径按下面两步走第一步改注册表。用管理员权限打开 PowerShell执行New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name LongPathsEnabled -Value 1 -PropertyType DWORD -Force Restart-Computer # 需要重启才能完全生效有些系统还可以在组策略里做同样的事计算机配置 - 管理模板 - 系统 - 文件系统 - 启用 Win32 长路径设为已启用。这两者的底层指向同一个注册表项。第二步确认应用本身支持。一个软件能不能处理长路径取决于它的 manifestapplication xmlnsurn:schemas-microsoft-com:asm.v3 windowsSettings longPathAware xmlnshttp://schemas.microsoft.com/SMI/2016/WindowsSettingstrue/longPathAware /windowsSettings /application如果你只是自己写点小工具可以直接在项目工程文件里加上这个 manifest有些跨平台框架比如 .NET 的App.config或app.manifest也有对应的配置开关。4.3 node_modules 目录暴涨才是真正的痛做前端开发的人应该深有体会pnpm 时代 node_modules 不再是每个包一层层嵌套但 npm 的旧项目里node_modules\package\node_modules\另一个包\...这种路径一层套一层随随便便就能超过 260 字符。有段时间我们整个团队在 Windows 上跑 npm install 一直莫名失败报错文件路径看起来完全正常最后一递归查才发现是路径长度超过了上限。针对这种项目结构问题靠开系统长路径开关能缓解一部分但更推荐的做法是把依赖安装目录挪到磁盘根目录附近的短路径比如C:\proj\mypj减少前面的父目录占用。使用 pnpm 的符号链接结构从根源上压缩层级。或者启用 npm 的--install-strategyshallow减少嵌套层级。如果你在 Windows 上做 React Native 开发这问题尤其常见。很多原生构建脚本会生成特别深的临时目录就算开了 LongPathsEnabled部分原生构建组件不声明 longPathAware 一样会挂。我的做法是给构建器单独配置一个短路径工作目录然后在构建命令里把临时根目录指过去绕开这个限制比在代码层面打补丁稳定得多。5. This client is no longer supported 和 Teams 停止个人服务第三方客户端的生命周期阵痛这波热搜里还有两类特别有代表性的no longer问题一个是服务端把旧客户端拒之门外另一个是产品线被整套停掉。两者放在一起看特别有意思。5.1 Gemini 登录失败客户端过期的诊断思路错误信息failed to sign in. message: this client is no longer supported for gemini co如果你用的是 Google Gemini 相关的第三方客户端、聊天室工具或自己写的 OpenAI 兼容代理这个报错通常意味着两件事要么客户端的 OAuth 授权流程太老Google 已经关闭了旧接口要么你用的 API endpoint 版本被服务端下架授权服务器在登录阶段直接拒绝了客户端标识。排查这类问题我一般按这个顺序确认客户端版本是不是最新。很多桌面客户端有自动更新但有的更新源不稳定只更新了一半导致本地依然带着旧版 OAuth scope。检查登录时请求头里的user-agent和客户端 ID。如果服务端有版本校验旧的标识会被直接拒绝。如果之前用的是一个比较老的 token去对应的云控制台重新生成一个。旧 token 的到期策略通常和服务端版本是绑定的版本一旦下线旧 token 也大概率跟着失效。如果是自建代理查一下代码里调用 Gemini API 时的 endpoint。generativelanguage.googleapis.com的接口地址一直在调整某些老版本 URL 会 404 或返回 not supported。这类问题没有一劳永逸的解决方案因为服务商更新接口后一定会淘汰旧客户端。更实际的做法是在运维监控里加一个周期性任务定期发一个健康检查请求到 API一旦发现返回 not supported就触发告警而不是等用户全部反馈了才去改。5.2 Teams 个人版停止运营产品生命周期变化的处理思路另一条热词是 Teams for personal use is no longer available。微软把原本面向个人用户的 Teams 免费版停了引导个人用户转向 Skype。这个对我们普通用户的影响主要是桌面上那个图标突然登不进去或者网页版跳转到一个提示页面。如果是个人使用场景相对简单换个官方替代品把聊天记录导出就行。但如果你所在的公司或自己接的小项目底层接口依赖了 Teams 的个人版登录链路比如用一个自动化脚本往个人账号的 Teams 里推消息这个停服会直接打断业务。这种整个产品线被停掉的情况任何人遇到都只能尽快迁移。通用思路是先理清你的系统里哪些地方依赖了这套认证和消息通道然后把发送端切到新的 API。以 Teams 为例企业账号对应的 Microsoft Graph API 权限模型和个人版完全不同你需要申请新的应用注册、重新配置权限并且接受消息交互的体验变化。其实很多client no longer supported问题的本质是平台方把支持矩阵收窄了对老版本一刀切。你改代码也好升级客户端也好最终要接受生态里永远存在被迫迁移这件事早点把核心功能的耦合拆出来替换的时候就不用伤筋动骨。6. Cursor 加载比预期更久AI 编辑器启动缓慢的排查链路还有一条热词是 cursor tanking longer than expected虽然 tanking 很可能是 taking 的手误但这个词在性能问题上倒也能对上号。实际场景是打开 Cursor结果看那个启动画面转了特别久比编辑器自己预测的时间长得多。6.1 先定位是编辑器本体慢还是被某个插件拉住了处理编辑器启动慢我一般不看网上保存的通用优化建议而是先做一次最小启动测试把变量隔离出来。在启动 Cursor 的命令行里加上--disable-extensions强制以无插件模式启动。如果启动速度恢复正常说明问题出在扩展层如果还是很慢那就要往索引、缓存、网络连接方向查。# Windows 命令行示例 cursor --disable-extensions另外AI 编辑器比普通 VS Code 系编辑器多了一个环节它就绪前可能会尝试连接模型服务、拉取模型列表或做账号鉴权。如果办公网络代理配置有问题这个过程会等到超时才会继续表现就是启动画面卡半天。6.2 几类常见的缓慢原因和对应处理第一类工作区索引过大。Cursor 启动时会对工作区做语义索引方便后面 AI 代码补全和检索。如果你的项目里有node_modules、构建产物、数据集这类大型目录又没有在索引排除列表里那它扫一遍的耗时非常惊人。解决办法是在 Cursor 的设置里把files.exclude和search.exclude配置好必要时直接给符号建一个.ignore文件。第二类同步和遥测。有的版本默认开启了设置同步启动时会向远端同步配置如果远端服务连接不稳定会卡在等待同步完成这个阶段。检查一下本地日志看有没有反复重试连接远程的痕迹有的话先在设置里暂时关闭 Settings Sync 或遥测。第三类插件里有一个或多个启动时拉取网络数据的插件。比如某些 AI 辅助插件启动时会检查许可证、拉取远程规则集、甚至尝试更新内嵌的模型索引。网络一慢线程就挂在那里。你可以逐个禁用最近新装的插件直到启动恢复正常。6.3 看日志比瞎猜高效得多遇到启动慢我最推荐的还是直接看日志。Cursor 基于 VS Code 生态用CtrlShiftP打开命令面板执行 Developer: Open Logs Folder会打开一个日志目录。里面有几个关键文件名比如main.log、renderer.log、exthost.log。启动慢的问题十有八九在 exthost 日志里能找到证据搜索timeout、retry、http error这类关键词能很快锁定是哪个扩展卡住了网络请求。如果是索引阶段慢在 Cursor 状态下栏搜索Indexing也能看到实时状态它会告诉你当前正在索引哪个目录。我个人的经验是AI 编辑器启动变慢超过一半的情况都是工作区太大 扩展太多 网络鉴权卡点这三个因素叠加的结果。把索引排除配置好之后启动时间基本可以回到秒开水平。7. 六类问题跑完一遍后的通用排查心法把这几个 LATENTLY 无关的问题放在一起看会发现它们有一条共同的应对链路识别关键字 - 核对版本 - 查变更记录 - 最小复现 - 单向迁移。具体一点说看到 no longer 相关报错第一反应别去改代码先去查对应工具的版本变更说明。绝大多数情况下是某个配置/接口被移除了官方文档里会有迁移指南。看到 longer than expected 这类时间描述先隔离外部变量再用日志定位卡点。启动慢、构建慢、登录慢本质上都要先找到瓶颈在哪个环节。所有这类问题都值得一个可复现的最小项目。不用把整个仓库拿来调试新建一个空目录只放最小的配置跑同样的操作如果问题复现了就证明是环境配置问题如果消失了那就是项目里某个部分拖累的。迁移的时候尽量一次性完成。比如 pnpm 配置迁移如果只搬 overrides 而漏了其他字段后面大概率还会再报一条类似的 warning。养成搜索全部关键词的习惯把配置项名当成键全仓库搜索一遍把所有相关引用一次性处理干净。最后再分享一个我自己的工作习惯每次处理完这类问题我都会把报错原文和解决步骤贴进团队的运维手册并主动去搜索一下当前版本还有没有其他 no longer 的配置指令。与其等问题一个个爆出来不如在升级计划里提前列一张废弃清单。这样下次再有人看到某些诡异报错时不只靠网上翻帖子还能在自己团队里找到一手排查记录。技术迭代这件事真的没法完全避免但被折腾一次和每次都折腾一遍之间差的往往就是这些排查链路和记录习惯。希望这篇笔记能帮你少折腾几轮。