脱码6年重新开工每一个技术选择都面临“当年习惯 vs 当下主流”的冲突。把我的纠结和决策过程完整记录下来。01 写在前面为什么会有这篇我发现一个现象老程序员重新出山最大的障碍不是学不会新技术而是面对海量选项不知道选哪个。6 年前的选择范围很小现在每个环节都有 5-8 个备选而且每个都有各自的拥护者。今天我不写结论写过程。把我这几天纠结过的四个核心选型问题完整复盘包括我为什么最终做了这个选择、放弃了什么以及这些选择之间的相互影响。02 问题一开发环境选 WSL2、虚拟机、还是双系统这是最基础也是最重要的决策它决定了后续所有开发体验。我的备选项方案核心特征6 年前我的做法双系统直接装 Ubuntu启动时选 Windows 或 Linux我以前就这么干过虚拟机Windows 里跑 VMware/VirtualBox 装 Ubuntu以前也是主流方案WSL2Windows 子系统Linux 内核轻量运行6 年前这东西刚出来不成熟Cygwin/MSYS2/MinGWWindows 下模拟 Linux 命令环境以前用过用来凑合跑 Shell 脚本补充说明Cygwin、MSYS2、MinGW 的本质类似——在 Windows 上重新编译 Linux 工具模拟 POSIX API让你能在 Windows cmd 里敲 ls、grep 这些命令。但它们只是“看起来像 Linux”底层还是 Windows。我的纠结过程一开始我的直觉是装双系统——最干净、性能最好、没有中间层。但我马上想到一个实际场景我晚上在家写代码突然要查一个 Word 文档或者用网银转账得重启进 Windows办完事再重启回 Linux。来回折腾两次写作状态全没了。双系统 → 排除。然后我考虑虚拟机。VMware 跑 Ubuntu性能损失 20% 左右不用重启就能切回 Windows。但问题是我在虚拟机里写的代码怎么用 Windows 的 IDE 打开文件共享配置起来麻烦而且 IO 性能差Maven 编译时能明显感觉到卡顿。虚拟机 → 待定。接着我看了 Cygwin/MSYS2/MinGW。这三者的本质是在 Windows 上模拟 Linux API让你能在 Windows 里敲 Linux 命令。6 年前我偶尔用过跑跑 Shell 脚本还行。但问题来了模拟终究是模拟。我要装的 Java、Maven、Docker它们需要的是真正的 Linux 环境不是模拟出来的命令行工具。Docker 需要 Linux 内核的容器能力在 Cygwin/MinGW 上完全跑不起来。Java 虽然能装 Windows 版但和 Linux 版的路径、编码、文件权限行为有差异后面部署到服务器时容易出问题。Cygwin/MinGW → 排除。最后我认真研究了 WSL2。它的本质是 Windows 内置了一个轻量级 Linux 内核和 Windows 共享硬件资源启动速度秒级内存占用可控。而且代码放在 Linux 文件系统里性能接近原生VS Code 可以直接通过 Remote 插件连接 WSL编辑体验和在 Windows 本地一样Docker Desktop 深度集成 WSL2容器直接跑在 Linux 内核上不需要 Hyper-V 虚拟机最关键的是Microsoft 官方文档和整个开发者社区的主流方案就是 WSL2。遇到问题搜一下解决方案一抓一大把。我的最终选择WSL2选它的核心理由不用重启就能同时用 Windows 和 Linux开发性能接近原生Docker 支持完美VS Code 无缝集成。我放弃了什么放弃了“纯 Linux 环境”的极简主义执念。WSL2 本质是 Windows 上的 Linux有极少数底层操作比如直接访问硬件受限但对 Java 开发来说完全够用。03 问题二IDE选 VS Code 还是 IntelliJ IDEA这是Java开发者最经典的争论。我的情况特殊——我6年前用的是 Eclipse这两个对我来说都是“新东西”。两个方案的对比维度VS CodeIntelliJ IDEA价格完全免费社区版免费Ultimate版年费约¥1500Java支持红帽插件包够用原生支持更强大Spring Boot支持但不如IDEA顶级支持Ultimate独有Vue/TypeScript原生支持极好支持较弱Docker集成免费插件功能完整Ultimate支持社区版弱Markdown写作原生支持极好支持一般启动速度秒开较重加载慢内存占用~200-500MB~1-2GB适用场景全栈开发、轻量项目Java重型项目、企业开发我的纠结过程我的第一反应是装IDEA社区版——毕竟我是Java开发者IDE就该用专业的。但我很快意识到一个事我的项目不是单纯的Java项目而是“Java 后端 Vue 前端 Markdown专栏”的全栈项目。如果用IDEA写Java很爽写Vue要切到VS Code写Markdown还要再切一个工具。来回切换工具很打断心流。而且IDEA社区版对Spring Boot和Docker的支持有限如果后面要升级Ultimate一年1500的支出对业余项目来说性价比不高。我现在的工作中也会用到VS Code。安装Java插件包之后代码补全、调试、Maven集成都有虽然不如IDEA丝滑但完全不耽误干活。最关键的是三个插件Remote - WSL直接在WSL里开发不需要配置任何路径映射打开终端就是Ubuntu bashDocker在VS Code里可视化管理容器启动/停止/查看日志一键操作GitLens看代码历史、谁改了哪行对理解项目演进很有帮助一个工具搞定全部工作流从Java到Vue到文档不用切来切去。这对我来说比IDEA的“Java更专业”更有吸引力。我的最终选择VS Code选它的核心理由一个工具覆盖全栈开发 Docker管理 文档写作工作流不打断而且完全免费。等到V2.0做大型Spring Boot微服务时如果感觉VS Code不够用了再切IDEA Ultimate也不迟。我放弃了什么放弃了IDEA在Java开发上的极致体验。VS Code的Java支持确实不如IDEA精致比如重构功能、Spring Boot专用工具等。但目前V1.0就几百行代码够用。04 问题三Java 8 还是 Java 17这是我最纠结的一个问题——没有之一。两个版本的真实对比维度Java 8Java 17发布时间2014年2021年支持状态已停止免费更新LTS至少支持到2029年Spring Boot 3.x不支持必须MyBatis-Plus最新版部分兼容原生支持语法特性基础Lambda/Streamvar、文本块、Records、switch表达式垃圾回收器G1较旧ZGC低延迟学习成本0已经会了12天适应新语法我的纠结过程我的第一反应是用Java 8。理由很充分我工作上用的就是Java 8。国企项目稳定第一JDK版本多年没动过。反哺日常工作。如果我用Java 17写个人项目平时工作还是用Java 8两套语法切换反而容易出错。用Java 8的话个人项目和工作完全一致写代码的熟练度可以直接迁移。零学习成本。平时工作中会用到一些不用额外学习就能直接开工。这条理由非常强——“反哺日常工作”对我来说是一个实实在在的需求不是借口。但随后我查了一下Spring Boot的最新版本要求——Spring Boot 3.x 要求最低 Java 17完全不支持Java 8。而我V2.0的技术方案已经确定了要用Spring Boot TSF微服务。如果我V1.0用Java 8写到了V2.0再用Java 17需要做的事情包括检查所有依赖的兼容性测试代码在17下的运行情况可能遇到第三方库的兼容问题学习Java 8-17的新语法这不就是“技术债”吗为了省现在12天的学习成本给未来埋一个23天的迁移成本不划算。关键转折点真正让我下定决心的是一个很现实的判断现在的 Java 8就是当年的 Java 6。我记得刚入行时老同事还在用 Java 6说“Java 8 变化太大不稳定”。结果没过两年整个行业就切到 Java 8 了。现在回头看当年坚持用 Java 6 的人后来迁移的成本远高于“早点学”的成本。Java 17 已经是 2026 年的主流 LTS 版本了。Stack Overflow 2025 年调查显示Java 17 已经成为 Java 开发者最常用的 LTS 版本超过了 Java 8。Spring Boot 3.x 强制要求 Java 17意味着未来两年内大量企业项目会陆续升级。至于“反哺日常工作”——我现在的判断是我在个人项目里先学会 Java 17 的新特性等公司将来升级时我就是那个“已经用过了”的人。如果我坚持用 Java 8等公司升级时我反而要从零学起。我的最终选择Java 17选它的核心理由V2.0 Spring Boot 3.x 的硬性要求、避免技术债、社区主流、个人项目带路反哺工作我放弃了什么放弃了“不用学直接写”的舒适区也放弃了个人项目和工作“完全一致”的便利。但这是短期换长期——Java 8 的舒适区会越来越小Java 17 的学习收益会越来越大。学习成本Java 8 到 17 的语法变化不大主要就几个新特性——var 类型推断、文本块、Record 类、switch 表达式。用两天熟悉就够了不耽误工期。05 问题四WSL 和 Cygwin/MinGW 什么关系为什么我没选后者这几个工具都解决同一个问题“在 Windows 上跑 Linux 命令”。但实现原理完全不同。一张表看懂区别工具原理能跑什么典型场景CygwinWindows 上重新编译 Linux 工具源码模拟 POSIX APIls、grep、bash 等在 Windows 上凑合用 Linux 命令MSYS2Cygwin 的改进版包管理更好同上 Git BashGit for Windows 自带的环境MinGWWindows 原生编译的 GNU 工具gcc、make 等Windows 上编译 C/C 程序WSL2Windows 内置真正的 Linux 内核任何 Linux 程序包括 Docker、JDK完整的 Linux 开发环境为什么最终不选 Cygwin/MinGW我 6 年前用过 Cygwin当时的感受是“能用但很别扭。”问题在于Cygwin 只是在 Windows 上“假装”是 Linux。你装一个 Linux 软件要先找对应的 Windows 移植版而不是直接 apt install。更关键的是Docker 这种需要 Linux 内核特性的软件在 Cygwin 上完全跑不起来。MinGW 更偏编译场景它让你在 Windows 上能用 gcc 编译 C 程序但和 Java 开发需求不匹配——我要的不是“能编译 C”而是“一个完整的 Linux 开发环境”。而 WSL2 是货真价实的 Linux 内核Ubuntu 里面装的任何软件都是原生的 Linux 版本不是移植的。Java 就是 Linux 版 JavaDocker 就是 Linux 版 Docker性能损耗极小。最终理解Cygwin/MinGWWindows 里的“Linux 模拟器”适合偶尔跑脚本或编译特定程序WSL2Windows 里的“Linux 内核”适合正经开发我的项目不是“偶尔跑脚本”是“长期开发一个完整产品”所以 WSL2 是唯一正确的选择。06 回头看这几个选择是相互关联的做完这四个选择之后我发现它们不是独立的而是相互依赖的WSL2在 Windows 上用 Linux 开发│├── VS Code通过 Remote-WSL 直接连进 WSL│ ││ └── 一个工具管所有Java Vue Docker Markdown│├── Java 17在 WSL 的 Ubuntu 里 apt install 直接装│ ││ └── 和 Docker 镜像里的 Java 版本一致无兼容问题│└── Docker Desktop深度集成 WSL2容器跑在 Linux 内核上如果选了双系统就不能无缝使用 VS Code WSL Remote如果选了 Java 8V2.0 切 Spring Boot 3 就要重构如果选了 Cygwin/MinGWDocker 根本跑不起来。技术选型不是孤立地选“哪个最好”而是要选“哪个组合最适配”。07 关于“反哺工作”的最终思考在 Java 8 这个纠结里我反复想了很久“反哺日常工作”这件事。最后的结论是用新技术做个人项目本身就是对工作的反哺。只不过方式不是“代码完全一致”而是“认知超前一步”。当公司将来从 Java 8 升级到 17 时我已经用了一年多 Java 17 了——var、文本块、Record 类、新的 Switch 表达式全都熟练了。到时候我不是“学习”而是“分享经验”。这才是真正的反哺。不是停留在原地陪跑而是先走一步带路。08 送给同样在纠结的读者不要追求“最好的”而是追求“最省事的”。对我来说VS Code 一个工具管全部就是最省事的而不是“Java 最强”的 IDEA。考虑未来两步而不是只盯当下。选 Java 17 而不是 8就是为了给 V2.0 省去迁移成本。反哺工作不意味着“和工作中用的一样”。先学会新东西等公司需要时你就是那个懂的人。选完就向前走不要反复纠结。这些选择对最终产品的成败影响其实没有想象中大真正重要的是把产品做出来。明天正式开始写代码。目标是让 ModelMatch V1.0 跑起来——输入问题输出推荐。下一篇预告个人 AI 产品 V1.0 需求极简拆解 —— 放弃完美业余开发只做核心价值