开发机基础环境
新电脑能打开 IDE，为什么仍然不能开发
一台刚交付的电脑通常可以打开浏览器和 IDE，但真正拉取项目后，问题才会集中出现：安装脚本拿到错误架构的软件包，终端和 IDE 使用不同的 JDK，浏览器能访问仓库而包管理器证书失败，管理员安装留下的缓存让普通账号无法写入，项目放在跨文件系统目录后构建突然变慢。
这些现象看似属于不同工具，实际都源于开发机的六层基础状态：操作系统与 CPU、软件来源、运行时版本、终端启动链、网络信任链、工作区与缓存。任何一层不明确，后面的 Git、构建、容器和调试都会把问题放大。
开发机工程化的目标不是让每台电脑像素级一致，而是让团队能够回答：哪些组合受支持，项目依赖什么，命令究竟从哪里来，失败从哪里取证，升级怎样回退，换机怎样重新构建。
六层基础状态
| 基础状态 | 先解决的问题 | 达成的结果 |
|---|---|---|
| 操作系统开发基线 | Windows、macOS、Linux、WSL 怎样选择，CPU、文件系统和权限有什么差异 | 能证明 OS、架构、账号和项目文件系统属于受支持组合 |
| 运行时版本管理 | JDK、Node.js、Python、Go 多版本怎样声明、切换并被项目识别 | 终端、IDE、构建工具和 CI 对同一项目解析到同一运行时 |
| 包管理器基线 | WinGet、Scoop、Chocolatey、Homebrew、APT、DNF 从哪里取包 | 软件来源、安装权限、升级、回退和卸载路径可追踪 |
| 终端入口与命令体验 | Terminal、Shell、Profile 分别做什么，启动文件和补全为什么失效 | 新会话能解释实际 Shell、PATH、Profile 和命令来源 |
| 代理、证书与 hosts 基线 | 系统、Git、包管理器、运行时和 IDE 为什么表现不同 | 每类客户端都能独立证明代理、DNS 与 HTTPS 信任链 |
| 工作区、缓存与权限 | 项目、缓存、临时和日志目录放在哪里，怎样安全清理 | 构建可写、缓存可定位、权限可恢复、清理有保护条件 |
按证据顺序建立开发机
不要先装完所有软件再一次性排错。更稳定的做法是每完成一层，就保存一份不含敏感信息的结果，再进入下一层。
第一步只探测系统，不急着安装：记录 OS、CPU 架构、当前账号、默认 Shell、文件系统和企业网络入口。第二步确定软件来源与权限模型，避免同一工具同时来自系统安装、用户包管理器和手工解压。随后再建立项目运行时声明，验证终端、IDE 和构建工具解析一致。
网络层不能用“浏览器能打开”代替。Git、包管理器、JVM、Node.js、容器运行时可能读取不同代理和 CA 存储，需要分别验证。最后把源码、依赖缓存、构建产物和临时文件放到边界清晰的目录，用普通开发账号完成一次真实项目闭环。
这个闭环至少包括：拉取仓库、安装依赖、运行测试、启动最小服务、完成一次本地改动，并能够解释命令来自哪里、配置从哪里读取、失败日志在哪里、临时资源怎样清理。只完成软件安装，机器仍处于“工具存在”状态，还没有进入“可开发”状态。
三类机器使用同一项目声明
| 环境 | 可以接受的便利 | 不能丢失的约束 |
|---|---|---|
| 个人开发机 | 用户级安装、版本管理器、本地缓存 | 项目版本声明、凭证隔离、环境可重建、资源可清理 |
| 团队受管开发机 | 统一镜像、软件中心、企业 CA、终端安全策略 | 例外审批、策略责任人、离线与代理验证、升级回退 |
| CI 或临时工作站 | 声明式镜像、短期凭证、一次性工作区 | 不依赖个人 Profile，不继承长期缓存和个人密钥 |
“我的电脑能跑”不能证明团队环境正确，“CI 能跑”也不能证明开发机的 Profile 和证书链正确。三类机器应读取同一份项目版本与依赖声明，同时保留各自的环境证据和凭证边界。
Git 的身份认证和代码审查会在代码协作继续展开；Maven、Gradle、npm、pnpm、yarn 的依赖解析进入包管理、构建与任务脚本；Docker 与 Podman 进入本地运行时与容器；抓包和复杂 TLS 取证进入网络、代理与证书。开发机基础环境为这些工具提供共同的系统、版本、网络和目录起点。
五类最容易被忽略的系统性风险
版本和路径污染
同一工具可能同时来自系统安装、用户包管理器、版本管理器、IDE、WSL 和手工解压。只看 --version 不能证明来源正确，还要记录可执行文件路径、当前进程架构、项目版本文件以及构建工具实际选择的运行时。
管理员权限污染
管理员终端能够暂时绕过安装和写入失败，却可能把项目、缓存或配置文件的 owner 留给管理员。日常判断标准应是普通开发账号能否完成构建；只有修改系统状态的动作才按需提权，并在完成后重新验证普通账号路径。
代理与信任库分裂
系统代理、Git、npm、Python、JDK、Docker 和 IDE 可能各自读取不同配置。系统已信任企业 CA，也不代表所有运行时信任。关闭 TLS 校验只会掩盖根因，并把开发便利变成凭证泄露和中间人攻击风险。
文件系统语义差异
Windows、WSL、macOS 和 Linux 对大小写、符号链接、执行位、ACL、路径长度和文件监听的处理不同。跨文件系统放置源码会放大这些差异，尤其是依赖数量多、频繁扫描并包含原生扩展的项目。
缓存和临时目录失控
语言包缓存、构建缓存、IDE 索引、容器数据和浏览器测试产物会持续增长。团队需要容量预算、清理脚本、排除目录和保留边界，不能等系统盘耗尽后让开发者手工删除未知目录。
开发机自检
OS、版本通道、CPU 架构和 WSL 使用方式属于团队支持组合。软件来源、安装权限、升级、回退和卸载路径可以追踪。JDK、Node.js、Python、Go 版本由项目声明，不依赖个人记忆。
新终端能证明实际 Shell、启动文件、PATH 和补全来源。浏览器、Git、包管理器和运行时分别通过代理与证书验证。工作区、缓存、临时和日志目录有责任人、容量预算和安全清理入口。
普通开发账号能完成拉取、安装、测试、启动和本地提交闭环。企业终端策略、离线源和企业 CA 的例外都有到期与恢复路径。换机、升级和设备退出时能够撤销凭证并重建环境。