刚入行的朋友问得最多、也栽得最狠的一件事基本上是“环境配置”。有人花一下午装好一个JDK最后卡在环境变量上有人从头到尾敲完一个项目最后只剩一句“在我本机跑得好好的”。这个系列从P01开始第一步就干一件最基础也最值钱的事把一套全栈开发工作台从零配好并且配到“可复现、可迁移、不用重蹈覆辙”的程度。这篇文章会围绕JDK、Git、Node.js、Maven、MySQL、VS Code这套组合展开覆盖目前主流的前后端全栈技术栈。整个过程以Windows为主但会把环境变量配置、镜像源、终端整合这些通用思路讲透换了macOS或者Linux也能举一反三。适合准备系统化开发、想顺便把机器上已有环境理清的读者也适合从零起步但不想走弯路的新手。1. 整体设计思路与工具选型1.1 为什么选这套技术栈P01这个系列的第一步本质上是解决一个组合问题哪些工具是“无论做什么项目都必须先有的”哪些是“等项目启动了再补也不迟”。我把前者提炼成五个基础件JDK负责Java后端编译运行Node.js承担前端工程化和部分工具链Maven管Java项目的依赖和构建MySQL承载数据存储Git负责版本管理VS Code作为统一的代码编辑入口。这套组合不是随便拼的。它对“全栈开发”这个词的还原度比较高如果后续要跑Spring Boot后端JDK和Maven缺一不可如果要做Vue或React前端Node.js是底线Git不碰基本无法参与协作。VS Code则作为轻量级编辑器把所有环境在同一个界面里统一调用。选它而不是IntelliJ IDEA这类重型IDE考虑很直接轻、快、插件覆盖面大前后端都吃得住。有些工具我也认真考虑过要不要这次就装比如Docker和Postman。Docker可以大幅简化环境隔离但它的底层依赖和网络模式对新手不太友好这个系列如果过早引入会分散主线。Postman是API调试神器但接口开发阶段再装更合适优先级押后。1.2 配置思路环境变量、版本和可迁移性配置环境变量的核心逻辑很简单让操作系统在一个全局位置登记工具的真实位置调用方只依赖登记名不关心具体路径。比如JDK装在C:\dev\jdk-17那JAVA_HOME指向它PATH里追加%JAVA_HOME%\bin以后升级JDK只要改JAVA_HOME这一个值就够了。这样的设计有两点好处。第一工具升级时不会影响到已经写好的业务代码因为代码里引用的是JAVA_HOME这个逻辑名第二环境变量的语义一目了然排查问题时一眼能看到目标指向哪。另一个关键是版本管理。JDK我推荐直接用17它是目前应用最广的LTS版本Node.js则强烈建议用nvm-windows来管而不是直接下载一个安装版。做全栈开发的人免不了在不同项目间切换有的项目锁定Node 14有的要求Node 18没有版本管理器你只能反复卸载重装非常消耗意志力。这不是“要不要麻烦一下”的问题而是环境能不能长期保持干净的问题。此外我把所有开发工具统一装在C:\dev目录下而不是默认的C:\Program Files。原因不复杂路径里有空格某些旧版脚本、命令行工具解析起来会出问题装到无空格目录能省掉一批奇奇怪怪的坑。2. 核心环境安装与验证JDK、Git、VS Code2.1 JDK 17环境变量配一次受益很久JDK的选择我用的是Adoptium Temurin 17也就是Eclipse基金会维护的OpenJDK发行版社区活跃、持续更新出问题也好查。去官网下载Windows x64的.msi安装包装到C:\dev\jdk-17。接下来最重要的一步是配置环境变量。打开系统属性里的“环境变量”窗口在“系统变量”里新建变量名: JAVA_HOME 变量值: C:\dev\jdk-17然后在Path里追加%JAVA_HOME%\bin。这里有个很多人容易混淆的点不要在Path里直接写死C:\dev\jdk-17\bin一定要通过JAVA_HOME引用。如果你以后再装一个JDK 21只需要把JAVA_HOME指过去所有依赖它的环境全部自动切换。配置结束后重新开一个CMD窗口旧窗口不会刷新环境变量依次输入两条命令验证java -version javac -version如果出现java version 17.0.x和javac 17.0.x说明JDK已经就绪。这里还有一个多年的老话题CLASSPATH到底要不要配。JDK 9之后就完全不需要手动配置CLASSPATH你在网上看到教人配classpath的教程基本都是十年前的产物可以直接略过。2.2 Git核心配置身份、换行符和默认分支Git安装本身没什么悬念下载Windows版一直下一步就行。安装过程中唯一需要留意的是“选择默认编辑器”那一步把VS Code选上以及“调整PATH环境”保持默认推荐项。真正容易踩坑的是装完之后的全局配置。第一次使用Git前至少要设置用户名和邮箱否则commit会报错。打开Git Bash执行git config --global user.name 你的名字 git config --global user.email 你的邮箱设置身份这件事远远不止“给commit打个标签”这么简单。团队协作时Git提交记录会关联到人代码托管平台上的账号绑定、代码审查、权限追溯全都依仗这组身份信息。我见过不少人跳过这一步结果提交记录里显示一堆“Unknown”后面要改历史非常麻烦。然后是换行符设置。Windows和Linux的换行符不一样CRLF与LF为了不让项目里出现“明明没改过代码diff却显示整行变化”的情况建议执行git config --global core.autocrlf true这个配置的意思是提交时自动把CRLF转成LF检出时再转回CRLF。如果你的团队成员都用macOS或Linux可以考虑input但true是Windows环境中兼容性最好的选择。顺便再设置一下默认分支名git config --global init.defaultBranch main现在Git初始化新仓库的时候默认分支就是main而不是有历史包袱的master这点也和主流托管平台保持了一致。2.3 VS Code的定位不是IDE是整个工作台的编排层VS Code在这里的角色不是单纯的编辑器而是把所有环境串在一起的“工作入口”。它通过终端直接调用上面配置好的Git、Node、Maven、Java工具链变成一个轻量但完整的开发工作台。即使后面接了更复杂的项目也没有必要急着换IDE。安装完VS Code后第一步先按CtrlShiftX打开扩展面板装一批基础插件。我用得最顺手的前几个是ESLint前端代码风格检查配合Vue/React项目几乎是刚需Prettier - Code formatter保存时自动格式化统一团队代码风格Java Extension Pack装上一组Java开发支持写Spring Boot时不用换IDEVue - OfficialVue 3的单文件组件语法支持GitLens在编辑器里直接查看每一行代码的提交历史和作者Chinese (Simplified) Language Pack界面汉化新手友好。插件装完之后还要做一件很容易被忽略但非常重要的事把Windows下的默认终端从PowerShell切换成Git Bash。步骤是CtrlShiftP输入Terminal: Select Default Profile选择Git Bash。这样一来VS Code里执行git命令、shell命令的能力和习惯完全统一避免两套终端环境带来的种种细微差异。到这里三件基础工具已经就位。你有了Java编译运行的环境、版本控制的工具以及一个能统一指挥这些工具的编辑入口。剩下的工作就是在这个台子上继续加装业务层的装备。3. 后端依赖与数据库Maven和MySQL的完整配置3.1 Maven不配国内镜像源等于每构建一次受一次折磨Maven是Java项目的构建工具承担依赖下载、编译、打包这些脏活。它的安装比JDK还简单去官网下载二进制压缩包解压到C:\dev\apache-maven-3.9.x然后配置环境变量变量名: MAVEN_HOME 变量值: C:\dev\apache-maven-3.9.9在Path里追加%MAVEN_HOME%\bin然后新开一个CMD窗口执行mvn -v看到版本信息就没问题了。但真正决定Maven体验的是conf/settings.xml这个配置文件。Maven默认从Maven中央仓库下载依赖这个仓库服务器在国外国内网络下经常慢到让人怀疑人生甚至直接超时失败。解决方法是配置阿里云镜像源以及一个本地仓库目录。用文本编辑器打开C:\dev\apache-maven-3.9.9\conf\settings.xml在mirrors节点里添加mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirrormirrorOf的意思是“什么样的仓库请求会被这个镜像接管”这里写central表示只接管中央仓库的请求不会影响其他类型仓库。同时在localRepository里指定依赖包下载到哪里localRepositoryD:/maven/repository/localRepository为什么不存放在默认的C:\Users\用户名\.m2目录一个非常现实的原因是系统盘空间一旦被依赖库占满各种问题会接踵而至而且系统重装后C盘无了依赖要重新下载。把它独立放到其他盘是给以后留的退路。验证Maven配置是否生效执行mvn help:system如果出现一堆下载进度条并且最终没有报错说明本地仓库和镜像源都正常工作了。这时候你再去创建一个Spring Boot项目依赖下载的速度会快到一个让人舒服的程度。3.2 MySQL 8.x安装、字符集与连接验证MySQL在开发环境里的坑主要集中在安装选项、字符集和远程访问控制这三件事上。我用的是MySQL Community Server 8.0下载MySQL Installer Community版里面可以顺带装MySQL Workbench。安装过程中有几个很容易被默认值坑到的点第一端口默认是3306如果机器上已经有别的服务占用了3306要么在安装时改端口要么后面去配置文件里改但建议尽量让它保持默认省得后面写连接串时还要多想一层。第二字符集选择。如果选默认的utf8mb4别急着以为万事大吉要在配置步骤里的“Collation”一栏确定排序规则选的是utf8mb4_0900_ai_ci这是8.0的默认值支持完整的Unicode字符集中英文、Emoji都能正常保存。第三root密码。开发环境可以设置一个当场记得住的密码但千万别把生产环境的密码也这么做。如果你有团队协作或本机调试远程连接的需求MySQL 8默认只允许本地登录要允许远程访问需要额外创建用户并授权CREATE USER devlocalhost IDENTIFIED BY 你的密码; GRANT ALL PRIVILEGES ON *.* TO devlocalhost; FLUSH PRIVILEGES;需要注意开发环境能不开远程访问就别开实在需要至少限定一个专用账号不要直接用root暴露出去。安装完成后验证数据库是否正常运行mysql -u root -p输入密码后能进入mysql提示符说明服务正常。再执行一条最简单的查询SELECT VERSION();返回8.0.x就齐活了。MySQL作为开发工作台里数据存储的一环到这一步完成了从安装到可连接的全部准备。4. 前端运行时与包管理Node.js和nvm的搭配4.1 用nvm-windows管理Node版本而不是直接安装直接去nodejs.org下载安装最新版Node.js很轻松但这是建一个全栈工作台里最容易留下坑的选择。真实项目里不同的前端工程化方案对Node版本有严格限制老一点的Vue CLI项目可能只兼容Node 14新版的Vite需要Node 18以上。没有版本管理器你遇到这种情况只能卸载重装。所以这里一定要用nvm-windows。先去它的GitHub仓库下载nvm-setup.exe安装到一个无空格的路径比如C:\dev\nvm。安装完成之后nvm会自动把NVM_HOME和NVM_SYMLINK写进环境变量其中NVM_SYMLINK指向的目录就是“当前Node的快捷方式”。这意味着你后续使用Node其实是通过一个软链接指向nvm管理的具体版本切换版本时只要改链接就好了。以管理员身份打开CMD依次执行nvm install 18.20.4 nvm use 18.20.4验证运行node -v npm -v设置nvm的Node镜像源显著加快下载速度。在nvm安装目录下的settings.txt里追加node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/4.2 npm源配置让依赖安装不再卡住Node装好之后npm默认的源是官方源在国内的下载速度同样一言难尽。设置国内镜像源是一个最基本的操作npm config set registry https://registry.npmmirror.com设置完可以执行npm config get registry确认一下是否指向了镜像地址。这一步对全栈开发的日常影响特别大——每次npm install都是在和镜像源打交道源快不快直接决定你每天是花5分钟等依赖还是花5秒等依赖。另外一个小建议执行npm config set init-author-name 你的名字 npm config set init-license MIT这样以后npm init生成的项目描述文件里会自动带上你已经写好的信息省得每个新项目手工改一遍。这个习惯是我自己多次手工补充信息之后总结出来的微不足道但省心省力。到这里整个工作台的核心部分已经齐全JDK和Maven负责Java这条路Node和npm负责前端这条路MySQL作为数据底座Git管版本VS Code做统一入口。把这几个要件放在一起其实你已经具备跑通绝大多数主流全栈项目的基本条件了。5. 工作台统一配置与终端整合5.1 让VS Code成为所有工具的同一个终端入口环境都装好之后最后一个要处理的问题是怎么让这些工具在一个统一的工作界面里被顺畅地调用。如果每次打开一个项目都要分别开一个CMD窗口跑后端、一个终端跑前端、一个Git窗口提交代码那环境再干净也白搭。VS Code内部集成的终端就是解决这个问题的那根线。把默认终端设置成Git Bash之后你在VS Code里就能同时做这些事在编辑器里写Java代码然后用集成终端执行mvn spring-boot:run在同一窗口另一侧打开新终端执行npm run dev启动前端需要操作数据库时直接在第三个标签页里跑mysql -u root -p所有Git操作甚至可以不离开编辑器用左侧的源代码管理面板完成。这就是“工作台”这个词的实际含义。它不是一个固定的软件界面而是你在开发过程中能够保持“在同一环境里连续切换任务”的能力。环境变量统一、终端统一、工具链统一这三件事凑齐了工作流的顺畅度完全不一样。5.2 settings.json里我建议必须改的几个配置VS Code的配置项多到记不过来但有几项是推荐新环境里在第一轮就改掉的它们对日常体验影响巨大。按CtrlShiftP打开“Preferences: Open User Settings (JSON)”在settings.json里加几行我长期在用的配置{ editor.formatOnSave: true, editor.codeActionsOnSave: { source.fixAll.eslint: true }, files.eol: \n, editor.tabSize: 2, terminal.integrated.defaultProfile.windows: Git Bash, git.autofetch: true }逐条说明editor.formatOnSave保存文件时自动格式化Prettier就是依靠这个配置工作的source.fixAll.eslint保存时自动修复ESLint能修复的问题前端的导入顺序、未使用变量这些小问题就不用自己动手了files.eol统一使用LF换行符结合Git的core.autocrlf可以在文件层面进一步避免跨平台换行问题editor.tabSize缩进统一为2个空格符合主流前端代码风格git.autofetch后台自动抓取远程仓库更新打开仓库就能看到远程分支的最新状态。这些配置不是越高深越好它们的作用一言蔽之把那些每天都遇到、但不想花心思记的重复劳动交给编辑器替你做。5.3 用code命令快速打开项目还有一个小习惯对开发工作流影响挺大用命令行直接打开VS Code。在VS Code里按CtrlShiftP搜索“Shell Command: Install code command in PATH”执行一次之后你就可以在任何终端里执行code .来打开当前目录项目。平时操作流程就变成cd到你项目所在的目录输入code .VS Code直接打开整个项目。这个命令和Git Bash配合几乎可以替代在资源管理器里逐层找文件夹的整个过程。全栈开发经常在多个项目之间切换这个操作能省下非常多的重复点击。6. 常见问题与排查技巧实录6.1 环境变量改了为什么还是提示“不是内部或外部命令”这是环境搭建阶段出现频次最高的问题。原因基本不会是配置本身写错而是“没有重开终端”。环境变量在进程启动的时候就会读取已经开着的终端窗口不会自动刷新。解决办法是彻底关掉当前CMD/PowerShell/VS Code重新打开一个新窗口再试。还有一种情况是以为自己改了系统变量实际改的是用户变量。两者同时存在时系统变量的优先级更高。如果你机器上两个边界都有同名变量排查时要两边都看一眼。再一个细节是Path里追加路径的时候不要把已有路径删了修改前先截图或复制一份原始值是比较稳妥的做法。6.2 JDK版本和项目要求的版本不一致很多报错信息看起来是“编译错误”或“不兼容类型”但根因其实是JDK版本不对。比如一个用Java 8语法写的旧项目在JDK 17下可能报无法访问或不支持发行版本之类的错误这时候先冷静检查本机当前java -version的结果和项目的pom.xml或build.gradle要求是否一致。解决方式有两类一类是修改项目的目标版本号在pom.xml里指定maven.compiler.source和target另一类是切换JDK。如果你打算长期做大项目可以考虑在机器上装两个版本的JDK通过修改JAVA_HOME来切换这也是当初强调用JAVA_HOME引用路径的原因——切换时只需要改一个值。6.3 MySQL服务启动失败或忘记密码的补救措施MSQL安装时默认会注册为Windows服务但偶尔会遇到服务无法启动的情况。第一反应应该是在“服务”管理窗口确认服务名是什么然后打开事件查看器看Windows日志里对应的错误详情。这个环节最常见的几个原因包括3306端口被占用、配置文件里指定的datadir路径无效、权限不足。如果服务就一直起不来还有一个比较直接的排查方向检查my.ini里配置的端口是否和安装步骤中设置的保持一致。端口冲突时改掉无效配置再重启服务通常就能解决。忘记root密码的场景也常碰到。方法是以管理员身份停掉MySQL服务然后用mysqld --skip-grant-tables临时跳过权限认证启动登录后改成新密码再重新启动服务恢复默认的认证模式。注意“跳过权限表”这种模式只适合本机本地紧急处理别开着这个模式跑业务代码那是灾难。6.4 npm install卡住或下载速度极慢造成这个问题的原因百分之九十是npm源没有配置好npm config get registry查一下如果还是https://registry.npmjs.org说明配置没生效重新执行一遍npm config set registry https://registry.npmmirror.com。如果已经配了镜像还慢留意一下是不是有某些特定依赖包下载的二进制文件走了单独的下载源。这些二进制文件有时候会指向GitHub Releases而GitHub的下载速度在没有特殊网络条件的情况下不可控。你可以优先检查项目里有没有.npmrc文件它可能会覆盖你全局配置的源地址必要时在项目级别的.npmrc里把对应依赖的镜像地址指到国内源。6.5 Git提交时diff显示整个文件被修改这个问题几乎每个跨Windows和macOS协作的团队都遇到过。文件本身没改动但Git认为每个换行符都变了。根因就是CRLF和LF混用。解决方式刚才在配置环节提过执行git config --global core.autocrlf true这能保证提交时换行符统一成LF检出时再按平台转换。如果是已经提交过、且仓库里已经混入了大量CRLF的文件仅靠配置不够需要对文件重新规范化。操作顺序是git add --renormalize . git commit -m chore: normalize line endings这一条命令会把整个仓库里的换行符统一刷新一遍比较干净。平时提交代码前养成用git diff确认一下的习惯也能提前发现问题。7. 写在最后环境配置的“真功夫”在坚持这一整套配置下来花了大致一两个小时但收益是长期的后续每次新建项目、切换任务、加入新工具链的时候你都会感受到环境是可控的。“为什么选这个版本”“优先级为什么这样排”“镜像源为什么必须配”这些细碎的选择比单纯的安装本身更值得记住。我个人还有个小习惯把每次环境搭建的具体版本号和配置过程记在一个固定的笔记里。等半年后机器出了新问题或者需要给别人搭环境时翻出来照着走一遍十几分钟就能复现整套环境比“凭记忆重新搜教程”靠谱得多。这大概也是P01这个系列最开始值得做的事——先把地基夯结实后面的一切才有得谈。