JetBrains IDE 家族
五台机器都能打开仓库，为什么只有一台能调试
团队给五位开发者分配了不同的 JetBrains IDE。所有人都能打开仓库、搜索符号，只有一位能在断点处停住；另一位的测试一直报模块不存在，第三位的 C++ 程序能编译却加载了错误 ABI 的库。把问题归结为“IDE 缓存坏了”并清空目录后，症状短暂消失，下一次切分支又全部回来。
根因通常不在编辑器皮肤，而在项目模型与执行边界没有对齐。WebStorm 要从 package.json、lockfile 和 Node.js runtime 还原 JavaScript 工具链；PyCharm 的解释器决定依赖和导入路径；GoLand 读取 Go SDK、go.mod 与 go.work；Rider 组合 solution、project、target framework 与 .NET 工具链；CLion 还要把构建系统、编译器、调试器和运行环境合成一套 toolchain。它们共享 IntelliJ Platform，却不是换了图标的同一款软件。
先选一个可信的代表仓库，在外部终端保存 npm test、python -m pytest、go test ./...、dotnet test 或 cmake --build 的结果，再让 IDE 消费同一入口。这样依赖下载失败、项目根选错、运行配置覆盖和项目分析异常才不会混成一个问题。Java、Maven 与 Gradle 的项目模型可沿 IntelliJ IDEA 工程手册继续验证；本地 Client 与远端 backend 分离后，应转到 JetBrains Remote Development 与 Gateway检查代码、进程、端口和凭证实际落点。
网络准备也属于执行链路。JetBrains 下载站、账号登录、插件仓库和语言依赖源分别走不同请求，企业代理、TLS 解密和内网 CA 必须逐层验证，不能用关闭证书校验换取一次成功。隔离环境除了 IDE 安装包，还要准备合同允许的激活方式、批准插件和语言工具链依赖；安装包能够拷入内网，并不证明项目能够离线构建。
共同底座：IDE 不拥有项目事实
五款 IDE 都会创建 .idea 目录、分析源码、提供运行配置、代码检查和插件入口，这种相似性很容易让团队把 IDE 配置当成项目本身。更可靠的顺序是：仓库描述构建，语言工具链执行构建，IDE 导入并调用它们，项目分析形成导航与检查需要的派生索引。JetBrains 当前帮助把旧版本里的 indexing 统称为 project analysis；术语变化没有改变事实：索引可重建，manifest、SDK 约束和源码才是输入。
项目导入插件把 manifest 转换成 IDE 内部的 module、source root、library 与 dependency graph，项目分析再以这张图建立符号索引。运行配置不会在索引里“运行代码”，它会带着工作目录、环境变量、SDK、参数和 before-launch tasks 启动外部进程；调试器随后通过语言对应协议附加到目标进程。启动成功但断点不命中时，应继续追踪实际 PID、加载模块与源码映射，而不是把“绿色运行按钮”当作链路已经正确。
因此，排障时不要一上来就“清缓存”。先问 IDE 打开的根目录是否正确、识别了哪个 manifest、选择了哪个 SDK、调用了哪个构建命令、启动了哪个进程。清缓存只能重建派生状态，不能修复错误的解释器、缺失的编译器、错误工作目录或无效许可。更完整的索引分层与恢复顺序见项目模型、索引与缓存治理，运行与调试的进程边界见任务、运行与调试配置治理。
用错误工作目录制造一个可诊断故障
下面的 PowerShell 实验不依赖 IDE 界面，它先证明仓库脚本可运行，再模拟 run configuration 把 working directory 指到错误子目录。JetBrains 五款产品的运行配置名称不同，但“可执行程序 + 工作目录 + 环境变量 + 参数”这组输入完全相同。
$lab = Join-Path $env:TEMP "jetbrains-working-dir-lab"
Remove-Item -Recurse -Force $lab -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path (Join-Path $lab "src") | Out-Null
@'
{
"name": "working-dir-lab",
"private": true,
"scripts": { "verify": "node src/check.js" }
}
'@ | Set-Content -Encoding utf8 (Join-Path $lab "package.json")
@'
const path = require("node:path");
const fs = require("node:fs");
if (!fs.existsSync(path.join(process.cwd(), "package.json"))) {
console.error("project-root-missing");
process.exit(2);
}
console.log(`cwd=${process.cwd()}`);
console.log("project-model-ok");
'@ | Set-Content -Encoding utf8 (Join-Path $lab "src/check.js")
Push-Location $lab
node .\src\check.js
Pop-Location
Push-Location (Join-Path $lab "src")
node .\check.js
$negativeExit = $LASTEXITCODE
Pop-Location
"negative_exit=$negativeExit"
Remove-Item -Recurse -Force $lab第一次运行应输出仓库根目录和 project-model-ok；第二次应以退出码 2 失败，并输出 project-root-missing。把 WebStorm 运行配置的 working directory 恢复到项目根后，同一脚本应再次成功。不能只用 npm run 构造这个反例，因为 npm 可能向父目录寻找 package.json，从而把错误工作目录暂时掩盖。这个现象也适用于 PyCharm 的模块导入、GoLand 的 go.work、Rider 的 solution 相对路径和 CLion 的 preset：先修复输入，再重建派生状态。
安装、启用与版本策略
个人开发机优先从官方入口安装 Toolbox App。在 Tools 中选择产品和稳定 Release 通道，为当前项目安装所需 IDE；确需验证升级时，再从 Available versions 并存一个新实例，不要直接让整组开发机自动跨大版本。Toolbox 可以保留上一版本以便即时回滚，也会因此占用更多磁盘；删除 previous versions 后，相应的即时回滚能力也随之消失。
standalone 安装适合软件分发系统已有固定包管理流程的团队，由 IDE 自己检查更新；Toolbox 管理实例的 IDE 更新策略则由 Toolbox 控制。Linux snap 适合快速个人使用，但自动更新、classic confinement 以及文件操作或调试限制，使它不适合作为强版本冻结团队的默认方案。完全离线时，从联网区下载与操作系统、CPU 架构匹配的官方安装包和校验信息，经制品入库与安全扫描后分发；插件也必须从受控仓库或已审核归档安装。
安装完成后先做四个不依赖业务仓库的检查：
Help | About 记录产品、构建号、运行时和插件基线。Help | Manage Subscriptions 或 Help | Register 确认许可类型与账号，不在截图、工单或仓库中暴露激活码。Settings | HTTP Proxy 通过官方测试入口验证代理；企业 CA 应进入受控信任链，而不是关闭 TLS 校验。
Settings | Plugins 确认只有批准插件。官方支持把 idea.plugins.host 指向内部插件仓库，但项目的 Required Plugins 仍只是缺失提醒，不是权限隔离或组织审批。
卸载 IDE 前先确认项目代码已提交或另有备份。IDE 配置目录、system/cache 目录和语言依赖缓存通常不会随卸载全部删除；清理这些目录会同时删除 Local History、索引和个人设置，不能当作无损操作。升级失败时优先回到上一 IDE 实例并保持仓库不变，只有确认配置迁移或缓存损坏后才清理派生目录。
许可不能按品牌打包推断。WebStorm 注册说明列出商业订阅、试用、符合条件的计划和个人非商业许可，非商业许可需要联网通过 JetBrains Account 激活，并受用途与数据条款约束；PyCharm 统一产品保留免费的核心功能，Pro 能力需要订阅；GoLand 没有 Community Edition，只有试用、付费订阅和符合条件的免费计划。公司业务应按实际用途分配商业席位，不能用个人账号或“代码还没收费”规避合同。组织浮动授权应采用当前可用的 License Vault / IDE Services 或合同允许的激活方式，不应新建已经退役的旧 Floating License Server。
WebStorm：项目是 JavaScript 工具链的工作目录
WebStorm 的 Node.js 支持从 package.json、lockfile、tsconfig.json、框架配置和项目内 Node.js 工具建立项目模型。它不应该替团队决定 npm、pnpm 或 Yarn 版本，也不应该用全局安装的 ESLint、TypeScript 替代仓库依赖。一个可复现项目至少要让包管理器与 lockfile 对应，并把 Node 版本约束放进项目认可的版本文件或团队基线。
打开已有项目后，先在 Settings | Languages & Frameworks | JavaScript Runtime 检查 Node.js runtime，再检查 package manager。monorepo 不要因为“顶层目录文件多”就只打开某个 package；应以 workspace 根及其 lockfile、workspace 定义为准。若只打开子目录，IDE 可能能编辑代码，却无法正确解析跨包引用、测试配置和根脚本。
最小验证应同时证明 CLI 和 IDE 使用同一工具链：
node --version
corepack --version
pnpm install --frozen-lockfile
pnpm test如果项目使用 npm 或 Yarn，就替换为仓库规定的命令。预期结果不是“编辑器没有红线”，而是依赖安装遵守 lockfile、测试进程退出码为 0，并且 WebStorm 的测试运行配置能命中同一测试。给目标函数加断点，通过项目脚本启动 Node 调试；断点命中后检查调用栈和变量，再正常停止进程。
常见故障是终端能跑而 IDE 报模块不存在。先比较 IDE 选中的 Node runtime、包管理器、工作目录和环境变量，再看依赖目录是否被误排除；不要先删除 lockfile。若 IDE 运行时调用全局包管理器而 CI 使用 Corepack，修复方式是把项目版本约束和 IDE 选择对齐，重新安装后再运行同一测试。
PyCharm：解释器是项目执行边界
PyCharm 的项目目录只告诉 IDE 源码在哪里，解释器配置才决定导入路径、依赖集合和执行平台。项目可以使用本地系统解释器、virtualenv、uv、Poetry、Pipenv 或 conda 环境；Pro 能力还覆盖部分 SSH、Docker、Docker Compose、WSL 等远程解释器。选型时必须区分“核心 Python 编辑与本地运行”是否够用，以及团队是否真的需要 Web 框架、数据库或远程目标等 Pro 能力。
打开仓库后检查状态栏解释器，再到 Settings | Python | Interpreter 查看可执行文件和包。不要把个人机器上的全局 Python 当团队基线，也不要提交 .venv。仓库应通过 pyproject.toml、锁文件或受控 requirements 描述依赖，通过 README 或任务脚本说明创建环境的方法。
下面是一条本地 virtualenv 的最小链路：
py -3 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
.\.venv\Scripts\python.exe -m pytestmacOS 或 Linux 使用 .venv/bin/python。预期结果是 PyCharm 选择同一解释器、测试可从 IDE 重跑、断点命中测试或入口函数。清理时先关闭 Python 进程并删除项目内 .venv，然后按同一依赖声明重建；不要删除源码、锁文件或团队配置来“重置环境”。
若 IDE 提示 Invalid environment，先用解释器绝对路径执行 --version，再确认环境没有被移动、基础 Python 没被卸载。若只有导入提示错误，比较 python -c "import sys; print(sys.executable); print(sys.path)" 与 IDE 解释器；随意把源码目录追加到 PYTHONPATH 可能掩盖包结构错误，优先修复项目安装方式或 source root。
GoLand：go.mod、go.work 与 GOROOT 各司其职
现代 Go 项目通常以 go.mod 定义 module，以 go.work 组合多个本地 module；GOROOT 指向 Go SDK，GOPATH 主要承载模块缓存和安装产物，不再是把所有业务源码都塞进去的项目根。GoLand 的 Go SDK 配置允许选择本地 SDK 或下载 SDK，团队机器仍应遵守仓库版本基线。选错根目录会导致 replace、workspace 和跨 module 导航与 CLI 不一致。
先在终端保留环境证据：
go version
go env GOROOT GOPATH GOWORK GOPROXY GOPRIVATE
go list -m all
go test ./...预期结果是 GoLand 选中的 GOROOT 与 go env GOROOT 对应，go.work 状态符合仓库预期，测试运行配置能重现 go test ./... 的结果。若使用私有 module，GOPRIVATE、Git 凭证、企业代理和 CA 是工具链配置，不应硬编码到 .idea 或 run configuration。
“cannot find package” 或依赖一直下载失败时，先看 go env 和 go list -m all，再看 IDE 是否打开了 module/workspace 根。修复后执行 go mod download 或项目规定的依赖命令并重跑测试。只有 CLI 正常而索引仍错误时，才考虑重新加载 Go module 或重建索引。
GoLand 官方 FAQ明确没有 Community Edition。学生、教师、开源核心贡献者等符合条件的计划与限期试用不能当作公司席位策略；商业团队应购买并分配许可证，或评估 IntelliJ IDEA 加 Go 插件是否已在现有订阅范围内，但仍需按当期产品能力和许可核实。
Rider：solution 是协作视图，project 与 SDK 才决定构建
Rider 的 solution 与 project 入口面向 .sln / .slnx、.csproj / .fsproj 等 .NET 工程对象。solution 组织多个 project、启动项和团队视图，target framework、PackageReference、编译属性则主要来自 project 与导入文件。Rider 只有在本机或目标环境存在匹配 .NET SDK、MSBuild 工具链和目标框架时，才能正确加载、构建和调试。
打开仓库时优先选择团队维护的 solution，而不是随意打开一个深层 project。先用 CLI 验证：
dotnet --info
dotnet restore .\YourSolution.sln
dotnet build .\YourSolution.sln --no-restore
dotnet test .\YourSolution.sln --no-build把占位 solution 名替换为仓库文件。预期结果是 SDK 版本符合 global.json（如果存在），restore、build、test 均成功；Rider 中选择正确 startup project，设置断点后 F5 命中，停止时子进程也按预期结束。
如果 Rider 显示 target framework 不可用，先看 dotnet --list-sdks 与 global.json，不要在 IDE 中随意把项目升级到本机已有版本。若 solution 加载正常但构建命令与 CI 不同，应让仓库任务或 solution 成为共同入口，而不是复制一套 Rider 私有参数。Unity、Unreal 或旧 .NET Framework 项目还受引擎版本、Windows targeting pack 和平台工具链约束，选择 Rider 前要把这些依赖纳入成本。
Rider 支持个人非商业许可，但公司业务、付费服务或商业产品应使用商业许可。跨平台 .NET 开发是 Rider 的重要优势；若团队强依赖 Windows 原生设计器、特定 Microsoft 工作负载或 Enterprise 调试能力，则应与 Visual Studio 工程手册 对照验证，不应按编辑体验单点决策。
CLion：toolchain 和 profile 决定你究竟编译了什么
CLion 项目格式覆盖 CMake、Makefile、JSON compilation database、Gradle、Meson、Zephyr West 等入口。对 CMake 项目，项目描述来自 CMakeLists.txt / CMakePresets.json；toolchain组合 CMake、构建工具、C/C++ 编译器、调试器和运行环境，CMake profile 再选择 build type、生成器、环境变量与选项。
这意味着“CLion 已识别 C++”远远不够。Windows 上可能使用 MSVC、MinGW、Cygwin、WSL、Docker；Linux 和 macOS 也可能在 GCC、Clang、远端或容器工具链间切换。ABI、标准库、架构和调试器不一致时，代码能索引但不能链接或断点无法绑定。
以 CMake 项目为例，先用项目规定的 preset；若项目尚未使用 preset，再显式指定独立构建目录：
cmake --preset dev
cmake --build --preset dev
ctest --preset dev若仓库没有 preset，可使用如下等价链路，但不要把生成目录提交：
cmake -S . -B build\debug -DCMAKE_BUILD_TYPE=Debug
cmake --build build\debug
ctest --test-dir build\debug --output-on-failure预期结果是 CLion profile 使用同一编译器、生成器和构建目录，目标可构建，测试通过，Debug 配置能命中断点。清理时优先删除可再生的 build directory 或执行项目定义的 clean；删除 CMakeLists.txt、preset 或 toolchain file 会破坏项目事实。
遇到 CMake reload 循环、编译器探测失败或断点空心，先查看 CMake tool window 和构建输出，比较 CMAKE_C_COMPILER、CMAKE_CXX_COMPILER、目标架构与 debugger。切换 compiler 后 CMake cache 必须重建；复用旧 build directory 常会把上一套编译器路径带进新 profile。
CLion 支持个人非商业许可，商业项目仍需付费。嵌入式、交叉编译、远端 Docker toolchain 等场景的价值不只在补全，而在于能否把真实编译环境映射进 profile；如果团队只有 Visual Studio solution 和 MSVC Windows 调试需求，先比较 Visual Studio 或 Rider 的原生工程模型，避免额外维护第二套 CMake 描述。
五款产品怎么选：先看项目事实，再看能力与许可
选型时可以用一张简表做第一次过滤，但最终必须以代表仓库验证，不以功能宣传页拍板。
| IDE | 项目事实与关键工具链 | 最适合的主场 | 许可决策重点 |
|---|---|---|---|
| WebStorm | package.json、lockfile、workspace、Node.js、TypeScript、测试与前端工具 | JavaScript / TypeScript 和前端、Node 项目 | 非商业个人可用免费许可；商业使用采购 |
| PyCharm | pyproject.toml / requirements、解释器、virtualenv / uv / Poetry / conda | Python 服务、数据与脚本 | 统一产品核心功能免费；高级能力核对 Pro |
| GoLand | go.mod、go.work、GOROOT、Go toolchain | Go module 与 Go 服务 | 当前注册口径为试用、付费、符合条件计划 |
| Rider | solution、project、target framework、.NET SDK / MSBuild | 跨平台 .NET、Unity / Unreal 等生态 | 非商业个人可用免费许可；商业使用采购 |
| CLion | CMake / Makefile / compilation DB / Meson、compiler、debugger、profile | 跨平台 C/C++、嵌入式和多工具链 | 非商业个人可用免费许可；商业使用采购 |
多语言 monorepo 不一定需要“一款 IDE 统治所有目录”。更稳的模型是仓库共享构建和格式化事实，每个子系统选最合适的 IDE，同时通过 EditorConfig、语言 formatter、检查脚本和 CI 门禁保证产物一致。只有当跨语言重构、统一搜索和单一席位成本带来明确收益时，才考虑把能力收敛到一款产品或 All Products Pack。
真实项目接入：把可复现链路交给仓库
新成员接入时，先 clone 到短而稳定的路径，在终端运行仓库 bootstrap / test 命令，再通过 IDE 打开顶层项目事实。项目文档只写“选择什么 SDK、运行哪条任务、预期看见什么”，不要保存某位开发者的绝对路径。
团队可共享的配置通常包括 .editorconfig、代码风格、inspection profile、部分 .idea 项目文件、.run 下不含敏感信息的运行配置，以及 .idea/externalDependencies.xml 中的 Required Plugins。个人窗口布局、最近文件、本地历史、凭证、解释器绝对路径、临时数据源和 workspace.xml 应留在本机。
共享 run configuration 前做一次逐字段审查：工作目录使用项目宏或相对路径；环境变量只引用占位符；token、密码和内网 URL 由本地环境或密钥工具注入；启动前任务调用仓库脚本；停止动作能结束子进程。若配置只能在作者机器运行，它不是团队资产。
常用提效动作要服务证据链
JetBrains IDE 的 Search Everywhere、Find Usages、结构化重构、运行配置、测试窗口、内置终端和 Local History 都很高效，但使用顺序应围绕“找到事实、执行同一任务、保存证据”。查找符号前确认索引范围，重构前确认 generated、vendor、build 目录被正确排除，运行前确认选中的 SDK 和 configuration，提交前比较 diff 并重跑仓库门禁。
Actions on Save 尤其需要克制。自动格式化、optimize imports、ESLint --fix、Prettier 或构建动作可能把一次小改动扩成大面积 diff。团队应指定唯一 formatter 与适用范围，优先只处理 changed lines 或由显式任务执行；启用前用干净分支做一次全仓 diff，确认换行符和生成文件不会被改写。
Local History 能救回未提交编辑，但它位于 IDE system 目录，不是备份或版本控制。清缓存、卸载、迁移机器前不要承诺它一定保留。真正需要审计和协作的变更必须进入 Git。
常见失败：按现象反推项目模型
终端成功，IDE 构建失败
CLI 测试通过，IDE 报 SDK 不存在、依赖无法解析或编译器找不到。
在 IDE 内置终端和 run configuration 中分别输出 Node/Python/Go/.NET/CMake 版本、工作目录与关键环境变量，并与外部终端比较。
IDE 选了另一套 runtime、没有加载 shell 初始化、打开了错误项目根，或 run configuration 覆盖了环境。
把 IDE SDK 指向项目规定版本，恢复正确项目根和相对工作目录；让启动配置调用仓库脚本，不复制一套隐藏命令。
外部 CLI、IDE terminal、IDE run 三处执行同一最小测试，输出版本一致且退出码为 0。
IDE 能运行，CI 失败
个人机器断点和测试都正常，干净构建缺依赖或生成文件。
检查是否使用了全局包、系统 site-packages、本机 GOPATH replace、未声明 SDK、IDE 自动生成代码或未提交配置。
IDE 和个人缓存掩盖了仓库声明不完整。
在干净目录按 lockfile、wrapper、module、solution 或 preset 重建；把必要步骤写进仓库任务，不提交缓存产物。
删除可再生环境后重新 bootstrap、build、test，确认不依赖旧缓存。
索引一直红，但构建成功
跳转和补全错误，CLI 与 IDE 构建却成功。
先看项目导入日志、source/excluded roots、生成源码和 SDK；确认近期是否切换分支、toolchain 或大量生成文件。
项目模型没有重新加载、生成目录未注册、索引派生状态损坏或插件不兼容。
先 reload 对应构建模型，再重建生成源码；禁用近期插件。最后才使用 invalidate / restart，并在操作前接受 Local History 可能受影响的风险。
选择一个曾错误解析的符号，确认定义跳转、Find Usages、测试和 CLI 构建四者一致。
登录或许可失败
账号浏览器回调失败、许可证不显示、离线机器无法激活非商业许可。
核对系统时间、代理、企业 CA、账号分配和产品是否匹配；确认使用的是 License Vault 或有效激活方式，而不是已退役 FLS。
网络回调被拦截、证书链被替换、席位未分配、许可类型不适用于商业用途，或非商业许可首次激活要求联网。
由管理员修复代理与信任链、分配正确产品席位；隔离网使用合同允许的离线激活方案。禁止使用破解、试用重置或篡改 VM options。
重启 IDE 后在 Manage Subscriptions 查看产品、账号和有效期，并由许可证管理员核对席位记录。
升级后插件或调试失效
新版本能打开项目，但插件被禁用、run configuration 异常或断点不命中。
在干净 IDE 实例中只启用必需插件，比较旧版和新版 build number、插件兼容范围、debugger 与工具链版本。
插件 API 不兼容、设置迁移污染，或升级同时改变了 runtime/toolchain。
回到保留的上一稳定实例，固定插件版本；将 IDE 升级和项目工具链升级拆成两次变更。
代表仓库依次完成导入、索引、build、test、断点、停止和重启，才扩大升级范围。
代理、权限、凭证与敏感信息
IDE 进程拥有当前用户可访问的源码、文件、环境变量和网络能力，插件通常与 IDE 同权限运行。安装插件前至少审查发布者、签名或来源、版本、兼容范围、网络行为和数据处理；Required Plugins 只能提醒安装，不能代替 allowlist、私有插件仓库或终端安全控制。
Backup and Sync 适合个人跨设备同步主题、快捷键、插件状态等 IDE 设置，不是团队配置中心。官方同步范围还可能包含 server certificates、数据库工具和其他系统设置；受监管团队应决定哪些类别允许进入账号云端。项目基线应通过仓库评审，许可证通过组织分配，二者不要混在个人账号同步里。
run configuration、HTTP Client 环境、数据库连接、Docker registry、私有 Go module、npm token 和 Python index 凭证都可能进入项目文件或日志。示例只使用 example.com、<token> 等占位符；真实值进入操作系统凭证库、受控 secrets 工具或本机忽略文件。提交前扫描 .idea、.run、日志和截图。
团队落地与架构深水区
第一，产品过多会把许可证和升级成本放大。按代表仓库和角色分配产品，维护“角色 -> IDE -> 许可 -> owner”清单；不要因为 All Products Pack 看起来省事，就默认每个人安装全部 IDE。半年复盘席位实际使用和非商业许可误用风险。
第二，项目配置容易被个人路径污染。团队明确 .idea 的允许清单与忽略清单，用干净 clone 验证共享配置。评审中一旦出现用户目录、内网地址、解释器路径或 token，阻断合并并轮换已泄露凭证。
第三，IDE 升级、插件升级和工具链升级叠加后无法归因。建立稳定通道与试点组，一次只改变一层；保留上一 IDE 实例和可重建插件清单。升级门禁至少覆盖五类代表项目中的实际子集：导入、索引、build、test、debug、stop、restart。
第四，索引与缓存会持续吃磁盘，也会掩盖项目缺陷。监测 system/cache、构建目录、包缓存和虚拟环境增长，按所有权分别清理。不要发布一条删除所有 JetBrains 和语言缓存的脚本；它可能同时抹掉 Local History、离线依赖和其他项目状态。
第五，远程与容器工具链会改变代码、进程、端口和凭证所在位置。一旦使用 SSH、WSL、Docker 或远端 backend，就要明确本地 UI、远端文件、插件、调试器和 license check 的边界，不能把本地项目模型原样套过去；对应部署链路可沿远程开发专题继续落地。
团队自检必须形成可复查证据
安装后确认 IDE build number、稳定通道、许可类型、代理、企业 CA 和批准插件；保留官方安装包或上一实例作为回退入口。
接入项目前先用 CLI 验证仓库，确认项目根和项目事实，再在 IDE 选择匹配的 Node runtime、Python interpreter、GOROOT、.NET SDK 或 C/C++ toolchain。IDE 与 CLI 必须运行同一 build/test 入口。
提交前审查自动格式化造成的 diff、.idea / .run 变更、绝对路径、账号、token、内网 URL 和日志。个人同步设置不能替代仓库基线。
团队推广前用代表项目完成导入、索引、构建、测试、断点、停止、重启和清理；记录产品许可、插件 allowlist、升级 owner、回滚版本与离职回收流程。选型结论应能说明为什么是这款 IDE、为什么不是相邻产品，以及退出时仓库仍如何通过 CLI 构建。