企业官网建设流程全解析

简介：面向Mac平台的前端开发环境搭建指南，覆盖Sublime Text代码编辑器、Package Control插件体系、Java SDK、Tomcat服务器及MySQL等数据库工具的环境安装与配置，适合刚接触Mac、需要从零搭建本地开发工作台的初学者，也可作为前端开发者快速部署环境的参考手册。资源以DOCX图文文档形式提供，共1个文件，压缩包约4.5MB，包含完整的步骤截图与命令说明；目前已有2164人学习下载。文档从Sublime Text的dmg拖动安装讲起，详细演示了通过控制台安装Package Control、Emmet与PyV8插件的手动部署，以及HTML5、CSS3、JS、jQuery等扩展的安装方法；随后覆盖Java SDK的下载安装与版本验证、Tomcat的目录权限修改与启停命令、MySQL的安装及初始密码保存等关键操作。每个环节都配有截图和终端指令，并提示了权限不足、注册弹窗、密码遗忘等常见坑点，方便读者按步骤完成整套环境配置并自查验证，一次搭好可用的前端开发环境。

1. 先想清楚一件事：Mac 上装前端开发环境，装的是什么

很多人在 Mac 上装前端环境的路径是：去官网下载一个 Node 安装包，一路下一步，装完 node -v 能输出版本，就觉得环境好了。过段时间换新电脑或遇到报错才发现，环境不是单个软件，而是一整套互相影响的链条——包管理器、Node 版本切换、编辑器、Git 和命令行工具。这篇笔记按“底座到应用”的顺序，把 Homebrew、nvm、Node、VS Code、Git 和 Java 相关配置过一次，重点写安装之外容易踩的坑。适合两类人：刚拿到新 Mac 想在一天内装完前端环境的，以及遇到 npm 权限报错、brew 装完找不到命令这类问题但没搞清原因的开发者。

2. 先把底座铺好：Homebrew 安装、换源与常用软件包管理

2.1 检查 Xcode Command Line Tools：装 Homebrew 之前先做这一步

在 macOS 上装 Homebrew，最常见的失败不是网络问题，而是系统里没有编译器相关的一套工具集。Homebrew 安装过程中会执行 git clone 和编译动作，依赖系统的 Command Line Tools（CLT）。第一次执行 xcode-select --install 会弹窗提示安装，等待几分钟完成。之后可以用 xcode-select -p 确认，正常输出 /Library/Developer/CommandLineTools。

注意，这里装的是 Command Line Tools 而不是完整的 Xcode。完整 Xcode 从 App Store 下载体积大、还会申请开发签名，对纯前端来说没必要。CLT 体积小得多，装完以后 gcc、git、make 这些命令都会补上。很多 brew install 报错信息里出现“xcrun: error: invalid active developer path”，基本上就是 CLT 缺失或路径被改过，重装一次就能解决。

# 验证 CLT 是否已安装，有输出则说明就绪 xcode-select -p

验证这一步跳过的人不少，等 brew 装到一半提示缺编译器再回头补，反而多花时间。CLT 装好后再执行 brew 安装脚本，成功率会高很多。

2.2 安装 Homebrew 主脚本：安装失败时的换源临时方案

Mac 上主流的 Homebrew 安装命令是一段长脚本，直接在终端执行即可。官方推荐命令是：

# 安装 Homebrew，需要管理员密码，会写入 /opt/homebrew（Apple Silicon）或 /usr/local（Intel） /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

第一次执行时脚本会先检测 CLT 是否存在，缺失则自动触发安装，整个过程会提示“Press RETURN to continue”，按回车后等待即可。curl 的 -fsSL 参数分别表示静默模式、失败时报错、跟随重定向。脚本本身负责创建目录、clone 仓库、写入系统配置，不是下载一个 dmg 拖进 Applications 那么简单。

安装脚本因为网络原因卡住时，常见做法是先设置镜像源再执行，脚本会从断点继续，不会重复安装：

# 使用镜像源安装，先导出环境变量，再执行官方脚本 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://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

这一组变量只解决 git clone 慢的问题。安装完成后，还需要把预编译包下载地址也指向镜像，否则后续 brew install 下载 bottle 时还是会去默认源碰运气：

# 设置 bottle 下载源为镜像，中科大或阿里二选一 export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.ustc.edu.cn/homebrew-bottles"

把上面这行写到 ~/.zshrc 里，每次新开终端都生效。Intel 与 Apple Silicon 的路径不同：Intel 装在 /usr/local，Apple Silicon 装在 /opt/homebrew。如果装完后 brew 命令找不到，多半是 shell 的 PATH 没更新，这在避坑章会专门展开。

2.3 brew 与 brew install --cask：命令行工具和图形软件分开装

Homebrew 两个子命令的分工：brew install 装命令行工具，brew install --cask 装图形软件（GUI 应用）。前端环境里两者都用得到，我一般会这样分：

# 命令行工具：git 新版、wget、tree、jq、ripgrep brew install git wget tree jq ripgrep # 图形软件：浏览器和编辑器 brew install --cask google-chrome visual-studio-code

命令行工具装完后以符号链接方式出现在 /opt/homebrew/bin 下，权限归当前用户，不需要 sudo；--cask 装的则是打包好的 .dmg 应用，位置固定在 /Applications，升级用 brew upgrade --cask，不用手动拖拽替换旧版本。

如果你在本地起后端做联调，可能会用到 MySQL、Redis 这类需要常驻的服务。brew 提供了 services 子命令统一管理：

# 安装并常驻一个本地 Redis，方便调试时起停 brew install redis brew services start redis # 查看当前服务状态 brew services list

这里要克制：brew services 管理的服务会开机自启，不适合拿来跑生产，本地调试很方便。下面是 brew 常用命令的速查表：

3. 装 Node 不只是下载安装包：用 nvm 管好版本切换

3.1 先看机器上已有的 Node：装之前查三处

很多教程一上来就是 brew install node，但如果你已经装了 nvm 或者系统里残留旧版本，后续一切都会乱。建议先花 30 秒查三个位置：

# 查看 node 是否已存在和它的来源 which node node -v # 查看 npm 全局目录前缀 npm config get prefix

which node 有输出，说明已经装过；没有则跳过。常见残留有两种：从 nodejs.org 下载 pkg 安装的，路径一般在 /usr/local/bin/node，并且会把 npm 的 prefix 指向 /usr/local，导致后续全局包要 sudo；另一种是 brew 装的 node，路径在 /opt/homebrew/bin。如果这两种同时存在，nvm 的 node 版本可能被 PATH 顺序覆盖。

我的建议是：留一个 nvm 管理的 node，把 brew 的 node 卸掉，pkg 装的用官方卸载脚本清理。这一步做干净，后面装包时的权限问题能省掉一大半。

3.2 安装 nvm：脚本方式与 shell 配置的完整过程

nvm 不是 brew 官方推荐的安装方式，brew install nvm 存在版本滞后和 update 需要手动的问题，我一般建议直接跑官方脚本：

# 安装 nvm，v0.39.7 是当前用得比较广的稳定版本 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

脚本会把 nvm 源码 clone 到 ~/.nvm，并且自动往 ~/.zshrc 或 ~/.bash_profile 里追加两行加载逻辑。装完以后，新开一个终端标签页再执行 nvm --version 就能看到版本。如果显示 command not found，多数情况是因为当前终端是安装前就开的，环境变量没有重新加载：

# 重新加载 shell 配置，再试一次 nvm 命令 source ~/.zshrc nvm --version

注意两个细节：第一，安装脚本默认从 GitHub clone，网络慢或失败时，可以先设置镜像再执行脚本，这个在避坑章会展开；第二，nvm 自动写入的配置依赖 $NVM_DIR 这个变量，如果你想自定义 nvm 安装目录，需要手动设置 NVM_DIR 再执行脚本，新手不建议折腾。

3.3 安装 Node 与 npm：换源、默认版本与项目锁版本

nvm 就绪后，安装 Node 本身反而比想象中简单：

# 安装最新的 LTS 版本，并把默认版本指向它 nvm install --lts nvm alias default 'lts/*' # 指定版本时用 nvm install 18 这类写法 node -v npm -v

第一次执行 nvm install --lts 时，nvm 会从默认源下载对应平台的二进制包并解压到 ~/.nvm/versions/node。如果下载速度慢或失败，先设置镜像变量再执行：

export NVM_NODEJS_ORG_MIRROR="https://npmmirror.com/mirrors/node" nvm install --lts

换源这个动作只对这一次生效，如果想以后都走镜像，把 export 写进 ~/.zshrc。Node 装好之后，npm 默认源也建议顺手换一下，避免后续 npm install 卡在拉包上：

# 把 npm registry 指向 npmmirror，一条命令永久生效 npm config set registry https://registry.npmmirror.com

关于版本锁定的问题：团队项目根目录一般会有一个 .nvmrc 文件，内容是一行版本号比如 18。进入项目目录后执行 nvm use 会自动读取这个文件并切换对应版本；如果本地没装这个版本，nvm 会有明确提示，方便你决定是 nvm install 还是看队友的配置。我在自己电脑上会额外执行 nvm alias default 18，保证新开终端默认版本稳定，而不是每开一个标签页都手动切。

3.4 包管理器延伸：pnpm 与 npm 权限的边界

npm 换源之后，再装全局工具就顺了。前端常用的是 pnpm，对 monorepo 支持更好，磁盘占用也更小：

# 用 npm 安装 pnpm，全局命令会落到 nvm 管理的 node 目录下 npm install -g pnpm pnpm --version

这里要说清一个容易翻车的点：node 是用 nvm 装的，npm install -g 的安装位置在 ~/.nvm/versions/node/<版本号>/bin 下面，不需要 sudo。如果你执行 npm install -g 时提示 EACCES permission denied，说明当前用的 node 不是 nvm 管理的，或者旧版 npm 的 prefix 指向了系统目录。

解决办法不是加 sudo——sudo npm install -g 只会让问题更隐蔽，而是查 npm config get prefix，确认它指向用户目录；如果指向 /usr/local，通常需要把系统里残留的 node 清掉，再回到 nvm 路线。这条血泪经验后面避坑章还会细说。

4. 编辑器、Git 与 JDK：装到“能干活”而不是“装得全”

4.1 VS Code 安装与命令行入口：图形软件装完还要补一条 CLI

前端环境里，VS Code 是目前默认主力编辑器，用 cask 安装即可：

brew install --cask visual-studio-code

装完第一次打开 VS Code，按快捷键 Cmd+Shift+P 打开命令面板，搜索“Shell Command: Install code command in PATH”，执行后会在 shell 的 PATH 里加入 code 命令。之后就能在任意终端目录执行：

# 用当前目录启动编辑器，或直接打开指定文件 code . code package.json

这一步容易被跳过，因为 VS Code 正常打开并不影响使用，但一旦你想在终端里用 code 打开项目，或者让 git 的 core.editor 指向 VS Code，就会发现缺了它很多操作不顺手。前端常用的插件（ESLint、Prettier、Vue Language Features 这类）按需装，它们更多是工程规范层面的辅助，不建议一开始装一堆。如果你习惯用 AI 辅助编码，可以关注与 Codex 类似的终端侧编辑器插件，这类插件需要保持终端网络可达，配置上比普通插件多一个授权步骤，建议按团队统一方案来，不用每个人都自己折腾一遍。

4.2 Git 与 GitHub 连接：新机器到手先配密钥

macOS 自带 git，但版本偏旧；前端环境建议直接 brew 装新版：

brew install git git --version

git 装完只是第一步，真正决定你能不能干活的是身份和远程连接。全局身份配置一条命令：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

远程连接我一般用 SSH 而不是 HTTPS：SSH 密钥配好后不需要每次输入密码，也避开了 token 过期的问题。生成密钥用 ed25519 算法：

# 生成密钥，-C 只是注释，方便识别是哪台设备 ssh-keygen -t ed25519 -C "your-email@example.com" # 查看公钥，复制到 GitHub 的 SSH keys 设置里 cat ~/.ssh/id_ed25519.pub

测试连接用 ssh -T git@github.com，第一次连接会提示确认主机指纹，输入 yes 即可。出现 Hi 开头加你的 GitHub 用户名就是成功。有个小坑：部分网络环境会把 SSH 的 22 端口拦截，报 connection timed out，这不是密钥问题，可以用 GitHub 提供的 443 端口方案规避，做法是在 ~/.ssh/config 里加一段配置：

# 追加到 ~/.ssh/config Host github.com HostName ssh.github.com Port 443 User git

另外 git 的默认分支名和编辑器也可以顺手设一下：git config --global init.defaultBranch main、git config --global core.editor "code --wait"，配合上一步的 code 命令，git commit 报错时会在 VS Code 里打开编辑器填写信息，比 vim 对前端更友好。

4.3 JDK 与 Maven：纯前端可以跳过，但别等用到时才装

严格说 JDK 不算前端环境，但做真实项目时经常绕不开：老项目用 webpack 构建依赖 Java 的典型场景是 Android 混编或者某些组件库的编译脚本；公司内部的发布工具也可能要求 JDK 8/11。所以我的判断标准是：遇到装不上或跑不起来的构建工具再回头补，但如果电脑是新机器，一次性装好也不算浪费：

# 用 cask 装 Temurin JDK，8 和 11 按项目要求二选一 brew install --cask temurin@8 # 装完检查 java 版本 java -version

macOS 上 JDK 多版本共存是常态，装完还要设置 JAVA_HOME 指向默认版本，才能让 Maven 和其他工具找到它：

# 在 ~/.zshrc 里追加下面的配置，/usr/libexec/java_home 是 macOS 自带的管理命令 export JAVA_HOME=$(/usr/libexec/java_home -v 1.8) export PATH=$JAVA_HOME/bin:$PATH

Maven 则推荐 brew 安装：

brew install maven mvn -v

mvn -v 输出里会显示 Java home 指向哪个 JDK，如果和你预期不一致，回到 JAVA_HOME 配置检查。这里多说一句：不要看到“缺 Java”就去装 Oracle 官网的完整 JDK，开发机用 OpenJDK 发行版（Temurin 就是其中一种）完全够，授权上也省心。如果你做的是纯页面开发、不跑任何 Java 构建链，这一小节的内容可以整个跳过，环境越小越不容易出问题。

5. 避坑记录：Mac 前端环境安装中最常出的 5 类问题

5.1 brew 装完却提示 command not found，多半是 PATH 没生效

现象：安装脚本执行到最后提示“Next steps”，终端却执行不了 brew，新开窗口也不行。

原因：Apple Silicon 上 Homebrew 装在 /opt/homebrew，但这个路径默认不在 PATH 里；安装脚本没有自动写配置，只是把要执行的命令打印在屏幕上。

解决：把 /opt/homebrew/bin 加入 PATH，标准做法是追加配置并重新加载：

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile source ~/.zprofile brew --version

Intel 机器地址是 /usr/local/bin，一般已经在 PATH 里，遇到同样问题就检查那一行有没有被 shell 初始化脚本覆盖。

5.2 nvm install 卡在下载节点上，换镜像源是标准操作

现象：执行 nvm install --lts，卡在“Downloading and installing”或进度条长时间不动。

原因：nvm 默认从 nodejs.org 下载二进制包，这一下载链路不稳定时会长时间无响应。这不是 npm 本身的问题，是下载源的问题。

解决：导出 NVM_NODEJS_ORG_MIRROR 再重装，源换成 npmmirror 的 node 镜像，包名不变、校验逻辑不变：

export NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node nvm install --lts

下载完成后不需要改回原值，这个变量只影响 nvm 拉取二进制源。

5.3 多个 node 并存，nvm 的版本不生效

现象：nvm use 18 后 node -v 却是另一个版本；或者安装了 node 18，跑项目时提示版本不对。

原因：机器上同时存在 brew 装的 node 和 nvm 装的 node。brew 的 node 符号链接位于 /opt/homebrew/bin，而 nvm 的 node 在 ~/.nvm/versions/node/...，如果前者出现在 PATH 更靠前的位置，后者会被覆盖。这种错位现象看着像玄学，其实是 PATH 顺序问题。

解决：确定只保留 nvm 管理的 node，brew 的 node 卸载掉：

brew uninstall --ignore-dependencies node # 执行后新开终端，确认输出的是 nvm 的版本路径 which node

同时把 ~/.zshrc 里手动添加过的系统 node 路径删掉。每次装完工具链，第一件事不是跑版本命令，而是查 which node 到底指向哪里。

5.4 全局包安装报 EACCES，别急着 sudo

现象：npm install -g pnpm 报 EACCES: permission denied，提示没有权限写入 node_modules 目录。

原因：npm 全局安装目录是 /usr/local/lib/node_modules，该目录归 root 所有，常见于从官网 pkg 安装 node 而不是用 nvm 安装的场景。网络上的老教程会让你 sudo npm install -g，这样确实能装上，但会让后续全局包都变成 root 权限，卸载时也很麻烦。

解决：回到用户目录的 node 管理方式。如果 node 已由 nvm 管理，检查 npm prefix：

npm config get prefix # 期望输出 ~/.nvm/versions/node/v18.x.x 下的路径

如果 prefix 指向 /usr/local，说明 nvm 的 PATH 配置没生效，回到 5.3 检查 node 来源。清理好历史再装全局包，就不用碰到权限问题。

5.5 端口占用与磁盘缓存：跑起来之后的常见干扰

现象：npm run dev 报“Error: listen EADDRINUSE: address already in use”；或者 brew upgrade 提示磁盘空间不足。

原因：端口占用是因为上次的 dev server 没有正常退出，或者 8080 被其他进程占用；磁盘空间不足常见于 Homebrew 的下载缓存和 npm 缓存越来越大。

解决：端口占用先用 lsof 查出进程再按需杀掉：

# 查看 8080 端口的进程，确认 PID 后决定是否结束 lsof -i :8080 kill <PID>

缓存清理按来源分开处理：brew 的旧版本包用 brew cleanup --prune=all 清，npm 的缓存用 npm cache clean --force；node_modules 反复安装造成的碎片只能靠项目目录整体删除重装。定期做一次环境清理，比遇到问题时再折腾省时间。

6. 装完之后：十分钟验证一次，再养成三个维护习惯

环境装完不建议马上开发，先花几分钟做一次整体验证，避免用到一半才发现某一环没通。下面这几条命令分别覆盖了包管理器、运行时、版本管理器的核心状态：

# 查 brew、node、npm、git 四个关键命令 brew --version && node -v && npm -v && git --version # 查 nvm 和当前 node 来源 nvm ls && which node

然后在一个临时目录跑一个最小项目，确认 npm 安装链路没问题：

mkdir -p ~/env-check && cd ~/env-check npm init -y npm install vite npx vite --version

如果这一步正常，说明 registry 源、npm 权限、node 版本、磁盘空间都处在可用状态。跑完把目录删掉即可。

维护习惯方面，brew update 和 brew upgrade 可以每个月跑一次，升级 cask 应用同理；node 版本不用追新，跟着 nvm alias default 指向的 LTS 走；出了问题先看错误信息的前十行，很多安装类错误在提示里就给了解决办法。

我自己的教训是：每次换新机器都把环境笔记翻出来，按固定顺序装，安装步骤一旦验证过就不再临场发挥。曾经因为赶时间，在一台新 Mac 上跳过了 Command Line Tools 检查，结果 Homebrew 装到一半失败，后续排查花的两个小时远超过老老实实装一遍的时间。整理一套自己的安装顺序，前两次踩坑后就不再折腾了。希望帮到你。

本文还有配套的精品资源，点击获取