企业官网建设流程全解析

最近好几个同事和读者都在问我同一个问题：刚拿到一台新电脑，mac也好、windows也好，怎么才能快速把开发环境装好。说实话，这类问题我见过太多——有人卡在装Homebrew，有人搞不定Windows下的Docker，还有人配个Maven能折腾一晚上。所以我把积攒的经验整理成了一套自动化安装脚本，项目代号“小龙虾”，寓意是“看起来小、外壳硬、剥开全是肉”：脚本本身很轻量，却能跨平台啃下各种安装难题，让小白也能快速上手把环境配齐。无论是mac还是windows，只要跑一条命令，常用的开发工具就能一次性装好；我把它公开出来的目的，就是希望这套方案能帮你把“装环境”这件烦心事变成一件不用动脑的小事。

1. 为什么我会写这样一套脚本

1.1 装开发环境的三个老大难

先说第一个痛点：跨平台。很多开发工具在mac和windows上的安装方式完全是两套逻辑。mac上大家习惯用Homebrew，一个brew install搞定大半；windows上则可能是安装包、解压版、包管理器混着来。如果你平时要在两台电脑之间切换，或者帮同事处理环境问题，这种割裂感会非常明显。我见过不少人为了在windows上装一个Linux风格的工具，硬生生折腾出各种兼容方案，最后还把系统路径搞得一团糟。

第二个痛点是包管理器碎片化。mac生态里Homebrew近乎一家独大，但windows这边有winget、Chocolatey、Scoop好几个选择，小白根本分不清该用哪个。就算选对了工具，很多软件还需要额外配置环境变量、处理依赖关系，比如JDK装完还要配JAVA_HOME，Maven装完还要改settings.xml。这些步骤单看都不难，串起来就很容易漏掉某一步，然后报错，然后百度，然后越弄越乱。

第三个痛点是报错信息对新手太不友好。安装Homebrew失败，可能只是网络源的问题；Windows脚本命令闪退，可能只是执行策略不允许；Docker启动不了，可能只是权限不对。问题本身都不算大，但定位问题对小白来说是大麻烦——你连错误日志该看哪一行都不知道。这三个痛点叠加起来，装机就成了一场劝退体验，尤其对刚转行做开发的人，第一关就卡住了。

1.2 我的目标：把“装环境”变成“跑一条命令”

所以我给自己定了一个很明确的目标：把装环境变成跑一条命令，而且这条命令在mac和windows上行为要一致，不能一个行一个不行。脚本要能自动检测当前是什么系统，自动选择对应的包管理器，自动跳过已经装好的组件，还能把每一步的日志记录下来，方便排查。

当时给我触动最深的是两个真实场景。一个是同事新买的MacBook，光是装Homebrew就折腾了两天，最后发现是默认源访问太慢，换了国内镜像几十秒就装完了，可这几十秒的经验他花了两天才摸出来。另一个是windows上跑Docker Desktop，安装包下好了，双击安装也成功了，结果启动的时候一直报“Error: start the windows daemon from a non-elevated terminal”，他完全不知道问题出在“非管理员终端”这几个词上。这两件事让我意识到，真正该被分享的不是某个具体的安装技巧，而是一套把这些技巧固化下来的自动化流程，让后来的人不用重复踩我踩过的坑。

“小龙虾”这个名字是我半夜起的，因为它符合这套脚本的三个特质：第一，个头小，整个项目只有几个脚本文件，没有复杂框架；第二，外壳硬，跨平台兼容性经过反复打磨，mac和windows都能稳定跑；第三，剥开有肉，表面看只是执行安装，实际上把检测、容错、日志、镜像加速这些细节都封装好了。后面我写的所有内容，都是围绕这三个特质展开的。

2. 整体架构与关键选型

2.1 统一入口、平台分发的设计思路

整套脚本最核心的设计思路是“统一入口，平台分发”。也就是说，用户不需要关心自己是什么系统，只需要执行同一个入口脚本，脚本内部会先做平台检测，然后进入对应的安装逻辑。这个思路其实借鉴了后端开发里的“适配器模式”：对外暴露同一个接口，对内根据运行环境选择不同实现。

具体到文件结构上，我是这样组织的：

• install.sh：mac/Linux入口脚本，bash编写
• install.ps1：windows入口脚本，PowerShell编写
• manifest.yaml：软件清单配置文件，统一描述要装哪些软件
• scripts/：按平台拆分的辅助脚本目录
• logs/：运行日志和状态文件目录

入口脚本放在最外层，使用者只需要下载两个入口文件加一个manifest就可以了。manifest的作用是把“装什么”和“怎么装”彻底分开：想在清单里加一个软件，不需要改安装逻辑，只需要在manifest里追加一条记录；反之，想调整安装策略，也不用动清单，只改脚本实现。这种解耦让我后续维护起来特别省心。

平台检测的逻辑我放在脚本最前面，mac上通过uname -s判断是不是Darwin，windows上则借助Git Bash或MSYS2环境识别MINGW、MSYS、CYGWIN这些标识。这里有个容易被忽略的细节：windows用户跑.sh脚本通常需要先安装Git for Windows，因为Git自带了一个完整的bash环境；但很多小白不知道这一点，所以我在windows入口处也预留了一个纯PowerShell的检测逻辑，两者配合，覆盖大多数使用场景。

2.2 为什么Mac走Homebrew，Windows走winget加Git Bash

选包管理器这件事，我纠结了很久，最后定下来的结论是：mac上只用Homebrew，windows上以winget为主、手动配置为辅，同时保留一个可选目录让用户用Scoop装一些更“Unix风”的工具。

这么选的逻辑很简单。macOS上Homebrew已经是事实标准，几乎所有开发工具都能通过brew install装到，而且它会自动处理依赖关系，brew services还能托管后台服务，比如MySQL、Redis这类。另一条路是手动下载安装包，但升级和卸载都麻烦，不值得。Homebrew唯一的坑是初次安装的网络问题，这个我在第5章会展开讲，解决办法是使用国内镜像源，脚本里已经内置了切换逻辑。

windows这边稍复杂一点。winget是微软官方包管理器，优点是系统原生、安全可靠、不需要额外安装；缺点是软件库没有Homebrew那么全，而且对命令行环境的表达能力有限。所以我让winget负责大头，比如Git、Node.js、Python这类常见工具；同时，我在脚本里保留了一个manual_install的函数接口，专门处理那些没有winget包的老旧软件，比如某些版本特定的JDK。Git for Windows是必装的，因为它不仅提供Git命令，还提供一个能跑bash脚本的Git Bash环境，这就让windows用户也能跑unix风格的安装脚本，一举两得。

下面这张表是我当初做选型时的对比，可以给同样纠结的人参考：

对于常用开发工具的选型，我也在manifest里做了分组，比如“基础工具组”包含Git、终端、文本编辑器，“语言运行时组”包含JDK、Node、Python，“数据库与容器组”包含Docker Desktop、Redis、DBeaver等。这样分组不仅便于用户按需选择安装，也为后面的交互式菜单埋下了伏笔。

2.3 幂等、日志与断点恢复

写安装脚本最忌讳的一件事是“装一半失败，重跑一遍全部重来”。所以我把幂等性作为整个脚本设计的硬指标：不管脚本执行几次，最终的系统状态是一样的，已经装好的组件不会被重复安装，没装好的组件会接着装下去。

实现幂等的关键手段是“安装前检查”。mac上执行command -v <软件名>，windows上在PowerShell里用Get-Command，如果命令已经存在，就认为软件已安装，跳过安装步骤；如果命令存在但版本不对，我还会用--version之类的参数做一次版本比对，发现不匹配就输出提示。这里有个例外：Docker Desktop这类GUI软件没有命令行入口，我改用检测安装目录的方式，检查/Applications/Docker.app或C:\Program Files\Docker\Docker\Docker Desktop.exe是否存在。

除了幂等检查，脚本还维护了一个状态文件，记录每一步的完成情况。每成功安装一个软件，就往状态文件里追加一行；下次运行时，先读取状态文件，已经标记完成的就直接跳过。这相当于给脚本加了一层“断点续传”能力——就算第8个软件安装失败，重新运行脚本时也不会再折腾前面7个。

日志方面，我把标准输出和错误输出分别重定向到logs/install_stdout.log和logs/install_stderr.log，同时在关键步骤打印时间戳。排查问题时，直接看stderr日志的前几十行，基本上就能定位到是网络问题、权限问题还是包本身的问题。这个习惯我养成了很久，现在已经是写脚本的标配了。

3. 核心实现细节与代码解读

3.1 平台检测与统一入口

先看mac和Git Bash通用的入口脚本核心片段。这一段的职责只有一个：搞清楚自己在什么系统上运行。

#!/usr/bin/env bash set -euo pipefail detect_platform() { local os os=$(uname -s) case "$os" in Darwin*) echo "macos" ;; MINGW*|MSYS*|CYGWIN*) echo "windows" ;; Linux*) echo "linux" ;; *) echo "unknown" ;; esac } PLATFORM=$(detect_platform) echo "检测到当前平台: $PLATFORM"

开头那行set -euo pipefail一定要写，-e表示任何命令失败就让脚本退出，避免带着错误继续跑；-u防止变量未定义；pipefail保证管道命令的失败能被捕获。这三个选项组合起来，是bash脚本的最基本防呆配置。

检测到平台后，脚本会根据平台读取manifest.yaml中对应的分组，然后调用统一的安装函数。对于windows场景，我的建议是先安装Git for Windows，然后用Git Bash运行这个入口脚本；如果你实在不想装Git，也可以直接运行PowerShell版本的install.ps1，两套入口我会在下一节说明。

3.2 安装函数的封装

接下来是这套脚本的核心：安装函数。我把它设计成“一个函数负责一个软件的完整安装生命周期”，包括检查、安装、验证、记录四件事。

install_one() { local name="$1" local installer="$2" if command -v "$name" >/dev/null 2>&1; then echo "[SKIP] $name 已安装，跳过" mark_done "$name" return 0 fi echo "[INSTALL] 开始安装 $name ..." if $installer; then echo "[OK] $name 安装成功" mark_done "$name" return 0 else echo "[FAIL] $name 安装失败，请查看日志 logs/install_stderr.log" return 1 fi }

这里的installer参数是一个“命令字符串”，我通过在调用方组合具体命令来复用这个函数。例如安装mac上的git：

install_one "git" "brew install git"

安装windows上的git（使用winget）：

install_one "git" "winget install --id Git.Git -e --source winget"

这种设计有一个好处：如果在windows上发现某个软件用winget装不了，我可以直接换一个installer参数，比如改成Scoop的install_one "git" "scoop install git"，而不需要改函数本身。套用一句做后端的朋友常说的话：面向接口编程，细节全部依赖注入。

3.3 软件清单与国内镜像配置

manifest.yaml我用的是最简单的键值结构，每个软件包含名称、安装命令、是否开机自启、备注等字段。下面是简化示例：

groups: base: - name: git mac: "brew install git" windows: "winget install --id Git.Git -e --source winget" - name: curl mac: "brew install curl" windows: "winget install --id cURL.cURL -e --source winget" runtime: - name: openjdk@8 mac: "brew install --cask temurin8" windows: "manual:jdk8_installer.exe"

windows里的manual:jdk8_installer.exe是一种声明式写法：当脚本遇到manual:前缀时，会去downloads/目录找对应的安装包，找到就静默安装，找不到就提示用户手动放入。这个设计解决了很多软件“官方只发安装包、不支持命令行安装”的问题。

另一个很重要的细节是镜像配置。mac用户装Homebrew时，默认源在国内环境下经常很慢，所以我参考常见做法，把brew的下载源切换为国内的开源镜像站，并把切换命令固化在脚本里，用户安装前会先执行一次镜像检测和切换。这样做的效果非常明显：原本可能要几个小时的任务，几分钟就能完成，而且完全不需要用户手工干预。Windows侧类似，winget本身走的是微软官方CDN，整体速度问题不大，所以镜像逻辑主要针对mac。

3.4 Windows侧PowerShell实现

PowerShell脚本不能直接用bash的command -v，但我尽量保持行为一致。先看平台检测和跳过逻辑：

$platform = "windows" function Test-Installed($name) { return $null -ne (Get-Command $name -ErrorAction SilentlyContinue) } function Install-One($name, $installer) { if (Test-Installed $name) { Write-Host "[SKIP] $name 已安装，跳过" Mark-Done $name return } Write-Host "[INSTALL] 开始安装 $name ..." try { Invoke-Expression $installer Mark-Done $name } catch { Write-Host "[FAIL] $name 安装失败: $_" Write-Host "请检查 logs/install_stderr.log" } }

这里有个细节：PowerShell里执行外部安装命令时，用Invoke-Expression虽然方便，但有安全隐患，因为字符串会被当作代码执行。更稳妥的写法是用Start-Process -Wait -NoNewWindow启动安装进程，并捕获退出码。我的脚本里对winget命令采用的就是这种方式，只在极少数需要调用PowerShell内部函数时才用Invoke-Expression。

另外，windows上执行任何需要改动系统的命令，都建议以管理员身份运行PowerShell。这一点很多小白会忽视，所以我在脚本开头加了一行明确提示：如果当前不是管理员权限，直接输出警告并退出，避免装到一半卡在权限弹窗上。实践下来，提前拦截比半途报错友好得多。

4. 实操记录：Mac和Windows各跑一遍

4.1 Mac端完整动手流程

拿一台全新的MacBook，从零开始装环境的完整流程是这样的：

第一步，安装Xcode Command Line Tools。这个工具包是macOS开发环境的底层依赖，Homebrew安装时也需要它。虽然在安装Xcode或运行git时会自动弹窗提示安装，但为了减少等待，我建议手动先跑一条命令：

xcode-select --install

它会弹出一个图形安装窗口，点同意，等几分钟就好。没有这个工具包，后面很多事情都跑不起来。

第二步，下载“小龙虾”脚本。我用的是git clone的方式：

git clone https://example.com/crawfish-installer.git cd crawfish-installer

自己使用的话，更推荐用git管理，之后更新直接git pull，可以保持脚本和manifest都是最新版本。

第三步，运行入口脚本：

./install.sh --quick

--quick参数表示使用manifest里默认的推荐分组，不做交互选择。如果你只想装某一部分，可以改成./install.sh --menu，会弹出一个简单的选择菜单。

脚本运行过程中，你会在终端看到类似下面的输出：

[INSTALL] 开始安装 git ... [OK] git 安装成功 [INSTALL] 开始安装 openjdk@8 ... [OK] openjdk@8 安装成功 [INSTALL] 开始安装 docker ... [OK] docker 安装成功

其实我建议第一次跑的时候不要离开终端，盯着看一会儿。如果看到某个软件卡住超过5分钟，十有八九是网络问题，这时候按Ctrl+C中断，检查日志，再重新运行脚本。由于幂等设计，已经装好的不会被重复装，所以不用担心中断会带来麻烦。

4.2 Windows端完整动手流程

Windows端的流程稍微有一点前置要求，因为整套脚本依赖Git Bash环境。步骤是这样的：

第一步，安装Git for Windows。这里我建议直接使用winget：

winget install --id Git.Git -e --source winget

安装完成后，在开始菜单找到“Git Bash”，打开它。注意这里不要用Windows自带的CMD或PowerShell跑bash脚本，否则会遇到各种路径兼容问题。

第二步，克隆脚本并运行：

git clone https://example.com/crawfish-installer.git cd crawfish-installer ./install.sh --quick

如果Git Bash弹出的安装提示影响了操作，或者你更习惯PowerShell，也可以直接右键管理员身份运行PowerShell，然后执行：

Set-ExecutionPolicy Bypass -Scope Process -Force powershell -ExecutionPolicy Bypass -File .\install.ps1 --quick

第一行Set-ExecutionPolicy Bypass是把当前进程的执行策略临时放开，避免PowerShell默认拒绝运行脚本。这里要强调-Scope Process，意思是只对当前窗口生效，不会永久修改系统策略，相对安全。

整个流程中，你可能会遇到Windows安全中心的弹窗，询问是否允许安装软件，正常选择“允许”即可。我见过不少人卡在“Windows Installer服务不可用”或“Visual Studio Installer服务不可用”的报错上，这类问题通常跟系统服务状态有关，我放在第5章里专门说。

4.3 安装成果验证

脚本跑完不等于环境真的可用，我习惯用一组验证命令确认安装结果。下面这张表整理了我最常用来验证环境的命令，mac和windows通用，只要终端里能正常打出版本号，基本就说明安装没问题。

验证时有一个细节：windows的CMD和Git Bash在显示中文路径或版本信息时可能有编码差异，如果看到乱码，不用慌，终端编码问题，不影响实际安装结果。另外，有些命令安装后需要新开一个终端窗口才能生效，尤其是环境变量改动，比如JAVA_HOME、MAVEN_HOME。所以正确做法是：脚本执行完后，关闭当前终端，重新打开一个新终端再跑验证命令，这样环境变量才真正加载。

5. 踩坑实录：常见问题排查

5.1 mac安装Homebrew失败或报错

Homebrew初装失败，是我在支持用户时遇到最多的问题。典型报错是curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused，或者卡在下载阶段长时间不动。本质上都是网络源访问不稳定，解决办法是用国内镜像源安装。

我在脚本里内置的方案是：先备份系统里可能存在的旧配置，然后切换到国内镜像下载安装脚本，再通过镜像源执行安装。核心命令逻辑类似：

export HOMEBREW_BREW_GIT_REMOTE="https://mirrors.ustc.edu.cn/brew.git" export HOMEBREW_CORE_GIT_REMOTE="https://mirrors.ustc.edu.cn/homebrew-core.git" /bin/bash -c "$(curl -fsSL https://mirrors.ustc.edu.cn/misc/brew/install.sh)"

注意这里不是所有Mirror都支持完整流程，我用下来比较稳的是中科大和清华的镜像，阿里的也可以，具体选哪个可以根据所在网络环境调整。安装完成后，还要把仓库地址也同步切成镜像，否则后续brew update还是会卡。

另一个常见的Homebrew报错跟目录权限有关，比如Error: /usr/local/opt/... not writable。这类问题通常是之前安装过旧版本或从Time Machine恢复过系统导致的，解决方法是重新设置目录属主：

sudo chown -R "$(whoami)" /usr/local/opt

如果你用的是Apple Silicon芯片的Mac，路径变成/opt/homebrew，操作方式一样。总之，先定位是网络问题还是权限问题，再动手，效率高很多。

5.2 Windows下脚本命令闪退或执行策略受限

Windows用户最常见的两个困惑：双击.ps1文件不运行，或者Git Bash里执行./install.sh一闪而过。

先说.ps1闪退。默认情况下，Windows的PowerShell执行策略是Restricted，禁止运行任何脚本，所以双击ps1文件通常就是闪退或者直接打不开。解决方案有两种：第一种是右键选择“使用PowerShell运行”，在弹出的窗口里可能会提示需要更改执行策略；第二种是像我前面写的那样，在当前窗口里先执行Set-ExecutionPolicy Bypass -Scope Process -Force，再运行脚本。这里不建议直接修改机器级别的执行策略，不安全，而且容易误伤其他正常软件。

再说Git Bash路径问题。如果你把脚本放在了一个带空格的目录下，例如C:\Users\My Name\my project\install.sh，直接./install.sh可能失败，因为bash会把空格后面的内容当成新参数。解决办法是给执行路径加引号，或者干脆把脚本放到一个纯英文无空格的路径下，例如C:\dev\crawfish。这个习惯可以避免很多莫名其妙的问题。

如果脚本闪退后什么都看不到，另一个可能原因是脚本的换行符格式不对。Git Bash要求脚本是LF换行，而windows记事本默认写出来是CRLF，CRLF在某些环境下会导致bash解析错误。我的仓库里已经设置了.gitattributes强制LF，但如果你自己改过脚本，可以检查一下，用VS Code右下角的“选择行尾序列”功能切换成LF，问题通常就解决了。

5.3 Docker守护进程启动失败

Windows上安装Docker Desktop后，启动时经常出现Error: start the windows daemon from a non-elevated terminal; shared clients，这句话翻译过来就是：你需要在一个有管理员权限的终端里启动Docker守护进程，普通终端没有权限操作Docker引擎。

解决办法很简单：右键以管理员身份运行PowerShell或CMD，然后再执行Docker相关命令。如果你用的是Git Bash，则要右键Git Bash选择“以管理员身份运行”。我在脚本里特意增加了一条检查，如果检测到当前用户不在管理员组，就会在安装Docker之后打印一行提醒，告诉用户“Docker安装完成，但请务必用管理员终端启动”。

还有一个容易误判的情况：Docker Desktop启动后，命令行执行docker version仍然报错，提示无法连接到docker daemon。这通常只是Docker Desktop后端服务还没完全启动，Windows上Docker Desktop启动较慢，尤其是首次启动要初始化WSL2和虚拟化环境。解决办法是等30秒左右再执行命令，或者用docker context ls查看当前上下文是否默认指向了docker-desktop。

5.4 Windows Installer服务不可用与端口占用

有用户反馈，安装某些软件时报“Windows Installer服务不可用”或者“Visual Studio Installer服务不可用”，这个报错听起来很吓人，但百分之八九十是因为系统服务被禁用或未启动。排查方法很简单：在服务管理器里找到“Windows Installer”，确认启动类型是“手动”并且状态是“已启动”，如果服务被禁用，右键改回手动再启动一次。

端口占用问题也是装环境时的高频问题，尤其是启动Elasticsearch、Redis或Tomcat这类服务时。比如你想在windows上启动Elasticsearch，提示9200端口被占用，这时候可以用下面的命令定位是哪个进程占用了端口：

netstat -ano | findstr :9200

输出结果里最后一列是PID，再用任务管理器或者命令行查看这个PID对应的进程：

tasklist | findstr <PID>

如果确认是无用的进程占用，可以执行：

taskkill /PID <PID> /F

这一套命令组合足够解决90%的端口占用问题。我强烈建议把这三条命令记在笔记里，因为以后不管是数据库、容器还是Web服务，都会遇到类似场景。但要注意，taskkill /F是强制终止，执行前务必确认进程不是系统关键进程。

5.5 Maven与JDK配置疑难

Maven装好以后跑mvn -v报错，是最典型的配置类问题。报错信息要么是JAVA_HOME is not defined correctly，要么是mvn: command not found。前者通常是因为JAVA_HOME指向了不对的目录；后者是因为Maven的bin目录没加到PATH里。

先说JAVA_HOME的正确设置。Mac上通过Homebrew安装的JDK8路径通常是/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home，不同版本的目录名不同，所以不能用死路径。我在脚本里用了一条动态查询命令来获取实际路径：

/usr/libexec/java_home -v 1.8

这条命令会输出对应版本的实际Home路径，输出结果直接写入~/.zshrc的JAVA_HOME环境变量即可。Windows端则建议直接使用安装包静默安装，安装完成后设置系统环境变量，脚本里通过PowerShell写注册表来设置JAVA_HOME和PATH，这里不再展开。

至于mvn: command not found，先检查Maven解压后的目录结构，确认bin/mvn文件存在，再把D:\apache-maven-3.9.6\bin加入PATH。改完环境变量后，一定要记得新开一个终端再验证，因为旧终端的环境变量不会自动刷新。

5.6 常见问题速查表

为了让你排查时少翻几页，我把上面几类问题汇总成一个速查表，按“症状 -> 原因 -> 处理方式”排列，可以当作备忘保存。

6. 这套脚本还能怎么扩展

写到这，有朋友可能会问：脚本已经能装这么多东西了，还能怎么改？我提供一个值得尝试的扩展方向：把脚本从“一次性安装器”升级成“持续维护工具”。

具体来说，可以做三件事。第一，把manifest.yaml改成可以分环境加载的多文件结构，比如manifest.dev.yaml、manifest.data.yaml，不同项目组切不同配置文件，这样团队新成员入职时，跑一条命令就能还原项目所需的完整环境。第二，在脚本里加交互式菜单，安装前勾选需要的组件，类似图形界面里的多选框，这对不熟悉命令行的队友非常友好。实际上现在的--menu参数就是一个简化版，后续可以扩展成支持上下键选择的分组界面。第三，把验证逻辑独立出来，做成verify.sh，既可以安装完自动跑，也可以随时手动执行，输出一套“环境体检报告”，包括版本、PATH状态、端口占用情况，甚至把系统安全日志备份也纳入报告范围。这个体检报告在排查问题时非常实用，相当于把“哪里有问题”变成了机器自动排查。

我最近还在实验一个新的方向：把容器工具链和本地服务管理也纳入脚本。比如把Dify、GPUStack这类AI应用部署工具的安装流程，通过调用docker compose的方式集成进来，让用户一条命令就能在本地拉起一个完整的AI应用环境。这套思路刚跑通原型，等我用熟了再单独写一篇展开。

最后说点实际的

这次公开“小龙虾”脚本，我最大的体会是：写安装脚本本质上是在跟未来的自己对话。每当我遇到一个问题，顺手在脚本里补一条检测、加一段注释，未来重装系统或帮别人排查时，就能少走一次弯路。这套脚本目前已经在我自己两台电脑上完整跑过三轮，mac端从格式化硬盘到环境就绪大约二十分钟，windows端半小时左右。我不敢说它覆盖了所有场景，但如果你和我一样，不想再为装环境浪费时间，完全可以先下载下来，按第4章的步骤跑一遍，遇到新问题再对着第5章的排查表对照一下。最后再分享一个小技巧：每次重装系统前，先把manifest.yaml里自己常用的软件组整理一遍，删掉不再需要的，补上新接触的，这样脚本每次重装都会更贴近你当下的习惯，装机这件事也会越来越顺。