新电脑开发环境初始化:一份可复用清单

换电脑最容易漏的不是编辑器插件,而是密钥、权限和能重复执行的安装顺序。本文给一份从系统到项目的初始化清单,让下一台机器按同一份文档装完就能开工。

新同事或新电脑开工慢,很少是因为某一个人”不熟悉工具”,而是因为安装顺序只存在于某个人的记忆里:先装什么、哪个版本、密钥放哪、哪个内部源要登录。记忆无法交给下一个人。这份清单的目标是:按文档做完,项目能在本机跑起来,而且没有把密钥留在错误的地方。

团队如果还在为”每人一套工具”消耗时间,先看 小团队工具链,再决定清单里哪些必须统一。

开工前先列不能丢的东西

动手安装之前,用半小时列出旧环境里真正不能丢的项。漏掉的往往不是软件,而是授权。

  • 代码托管的账号和双重验证方式。
  • SSH 密钥或证书:哪些可以重新生成,哪些必须转移。
  • 包源、容器镜像源、内部 npm 或 Maven 仓库的登录方式。
  • 密码管理器本身能否在新机器登录。这是其他密钥的入口,应最先确认。
  • 编辑器配置如果存在仓库或设置同步里,记下仓库地址,而不是从旧电脑整盘复制。

列不出来的项目,不要靠”装完再说”。等环境装到一半才发现没有内部源的权限,前面的时间基本白费。

建议固定的安装顺序

顺序比工具品牌重要。下面的顺序是为了让每一步的失败原因容易看出来:先有系统工具,再有语言运行时,再拉代码,最后才是编辑器和项目依赖。

顺序装什么怎样算通过常见失败
1系统更新、命令行工具终端能打开,基础命令可用跳过系统更新导致后面编译失败
2版本管理器,而不是单个语言包能按项目切换版本全局装了一个和项目不符的版本
3代码托管登录与 SSH能拉取指定仓库密钥权限过大或忘了作废旧钥匙
4包管理器与内部源能安装项目声明的依赖源地址写在个人配置里,没进文档
5容器或数据库等项目依赖项目文档里的健康检查通过端口被旧容器占用
6编辑器与格式化保存时格式与仓库配置一致插件版本和仓库要求不一致

第 2 步强调版本管理器:Node、Python、Java 这类运行时,用能读取项目版本文件的工具,避免”我机器上是好的”。项目根目录里的 .node-version、.nvmrc 或等价文件,应写进清单,并说明用什么命令安装对应版本。

第 5 步不要默认每个人都需要容器。只有项目文档要求时才装。多一个没人升级的本地数据库,就是多一个”只有我这台能跑”的来源。

密钥和登录态不要进仓库,也不要进聊天记录

初始化文档里最危险的写法,是贴出一串可用的密钥”方便复制”。文档只写去哪里申请、申请哪种权限、放在哪个本地文件。

  • SSH 密钥在新机器生成,把公钥加到托管平台,给最小权限。旧机器退役时删除对应公钥。
  • 令牌放在本机环境或密码管理器,用项目提供的示例文件(如 .env.example)说明变量名,不提交真实值。
  • 不要把浏览器用户目录整份拷贝到新电脑来”省得重新登录”。那里面不止有你想要的登录态。
  • 内部源的密码如果必须写进配置文件,文件权限收紧,并且该文件在全局忽略列表里。

和云上部署相关的令牌,遵循同一条:本地能部署,不代表可以把令牌写进仓库。静态站点的发布方式见 Cloudflare Pages 部署,密钥仍应留在平台的密钥管理里。

脚本可以帮助安装软件,但脚本里不应出现密码。需要登录时,脚本打印下一步让人完成,然后检查命令是否已经可用,不可用就停。

把清单写成可以打勾的文档

一份没有人维护的清单,两三个月后就会骗到下一个人。写成仓库里的 Markdown,和代码放在一起,比放在个人笔记里更可能被改。

每一步用同一格式:

  1. 做这件事的命令或界面路径。
  2. 成功时你会看到什么。
  3. 失败时先查哪一条,而不是”问问某某”。

“问问某某”可以写在最后当升级路径,但不能是唯一步骤。某某休假时,清单应该仍然能用。

编辑器插件只记录项目需要的那些:格式化、语言支持和仓库指定的扩展。主题、图标、个人快捷键写在个人备份里,不写进团队清单。统一个人审美不会让项目更容易跑起来。

用一次真实的装机来验收

清单写完不要自己觉得完成。验收方法只有一种:找一台没有这个项目环境的机器,或一个空的用户目录,让另一个人只看文档操作。你坐在旁边但不说话。他卡住的地方,就是文档要改的地方。

验收通过的标准:

  • 能拉下代码并安装依赖。
  • 项目文档里的启动命令可以跑。
  • 测试或健康检查至少通过项目声明的那一项。
  • 全过程没有把密钥提交进仓库。可以用提交前的检查或忽略规则兜住。

之后每次有人按清单装机,要求他把偏差改回文档再合入。这比指定一个”文档负责人”每季度重写一遍更可靠。超过一个季度没有人走过,就主动安排一次空目录演练。运行时版本会变,内部源地址也会变,没走过的清单默认是过期的。

自动化能帮忙的部分,例如检查版本、安装依赖,可以放进仓库脚本或 GitHub Actions 里,让”我机器上能跑”在合并前就被发现。本机初始化清单解决的是脚本开始之前的那一段:账号、密钥和系统工具。

常见问题

应该做成一键脚本吗?

系统工具和运行时可以脚本化。登录和授权必须停下来由人完成。脚本里不写密码,失败时说明下一步,而不是静默跳过。

旧电脑上的密钥可以直接拷贝吗?

能重新生成的就重新生成,并作废旧公钥。必须转移的秘密放进密码管理器,不用网盘和聊天工具传私钥。

编辑器配置要统一吗?

统一运行时、依赖安装和格式化。主题和快捷键随个人。项目在文档描述的环境里能跑,就够了。

怎么防止清单过时?

每次按它装机,就把卡住的步骤改回仓库。一个季度没人用过,就用空目录走一遍,失败的命令当场更新。

#开发环境#清单#密钥#上手

常见问题

把安装命令都写进一个一键脚本好不好?
系统级工具可以脚本化,登录、双重验证和付费授权不行。脚本应在需要人操作的地方停下来说明下一步,而不是把密码写进脚本里自动填。
密钥能从旧电脑直接拷贝过去吗?
SSH 私钥和浏览器里的登录态不要用网盘同步。能重新签发的密钥就重新签发,旧钥匙在确认新机器可用后作废。必须转移的,用团队认可的密码管理器,不用聊天工具发文件。
每个人编辑器插件不一样,清单要统一到什么程度?
统一运行时版本、包管理器、代码格式化和密钥存放位置。主题和快捷键不必统一。项目能在清单描述的环境里跑起来,就达到目的了。
清单写完怎么知道没有过时?
每次有人按清单装新机器,让他把卡住的步骤改回文档。超过一个季度没人按它装过,就指定一个人用空目录走一遍,失败的步骤当场改。