确认pnpm是否启用硬链接最底层方式是检查node_modules/.pnpm中文件inode号是否重复：Windows用Get-ChildItem | Select-Object Name, LinkType查HardLink，macOS/Linux用ls -i看相同inode号；更可靠的是运行pnpm store status，输出“Hard links are supported”才真正生效，该命令检测全局存储状态，不依赖当前项目。
怎么确认pnpm用了硬链接
直接看node_modules里文件的inode是否重复，是判断硬链接最底层的方式。Windows用户用PowerShell执行Get-ChildItem node_modules/.pnpm | Select-Object Name, LinkType，若大量显示HardLink即生效；macOS/Linux用ls -i node_modules/.pnpm，相同inode号对应同一物理文件。
更实用的方法是运行pnpm store status：输出包含Hard links are supported才算真正启用。注意这个命令不依赖当前项目，它查的是pnpm全局存储状态。
- 如果输出
Hard links are not supported，说明文件系统不支持（如Windows NTFS未开启开发者模式）或pnpm版本过旧 -
pnpm store path能查到硬链接实际指向的根目录（比如~/.pnpm-store），VSCode断点跳转错乱时要先盯住这个路径 - 别信
ls -la node_modules/xxx看到的->符号——那是软链接，和硬链接无关
VSCode里硬链接导致断点失效怎么办
断点停在~/.pnpm-store里的源码而不是你正在编辑的文件，本质是VSCode调试器把硬链接目标当成了“真实文件”。它没意识到项目内node_modules/xxx只是指向全局存储的引用。
关键不是禁用硬链接（那等于放弃pnpm核心优势），而是让VSCode明确以项目路径为权威：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 在
.vscode/settings.json中加"typescript.preferences.importModuleSpecifier": "relative"，避免TS自动补全时生成~/.pnpm-store绝对路径 -
launch.json里必须设"sourceMaps": true，并配"outFiles": ["./dist/**"]（如果用TS编译） - 删掉
launch.json里可能存在的runtimeExecutable硬编码路径——它会让调试器绕过pnpm的路径解析逻辑
为什么ESLint或Import Cost插件报错
这类插件默认遍历node_modules目录结构，但pnpm的硬链接让fs.readdirSync读到的是链接而非真实子目录，结果package.json找不到、模块路径解析失败，最终报ERR_PNPM_NO_PACKAGE_MANIFEST或静默降级。
没有通用修复，只能针对性处理：
- ESLint：在
.eslintrc.js里显式配置settings: { 'import/resolver': { node: { extensions: ['.js', '.ts'] } } }，绕过插件默认的node_modules扫描 - Import Cost：直接禁用，它依赖静态AST分析，硬链接下无法准确计算依赖体积
- npm Intellisense：彻底停用，它根本无法适配pnpm的扁平化+硬链接混合结构
硬链接检测容易被忽略的细节
硬链接本身不可见，所有检测手段都依赖间接信号。最容易漏掉的是文件系统层的支持状态——比如Windows用户开了pnpm但pnpm store status始终不显示Hard links are supported，问题不在pnpm配置，而在NTFS未启用开发者模式。
另一个隐形坑是VSCode重启：改完.vscode/settings.json后，必须彻底关闭所有VSCode窗口（任务管理器确认Code.exe进程消失），否则硬链接相关配置不会生效。Developer: Reload Window只刷新前端，不重建终端和调试器进程环境。
