关于开发环境搭建 —— 在 2026 年请 Ai 指出过时文章存在的问题会得到什么样的结果
作案动机
在 2026 年回头看 WSL2 Ruby on Rails 开发环境搭建笔记 ，随着 WSL 的完善，里面提到的一些处理方案都已经过时或是变得没必要了（或者是在 2022 年 WSL 开始支持 systemd 的那一刻就开始过时了）。但是一直懒得写一篇新的 blog 来替代它。
今天突发奇想让 AI 来看看旧的文章，直接帮我写一篇新的，于是就拜托 Gemini 帮了个忙。我要先吐槽一下 Gemini，即便启用了 URL context，在响应我的第一次提问时它显然并没有去阅读文章的内容，知道我贴上文章内容再次提问，它才好好回答。你也可以点击下面的分享链接直接查看这个对话，我也会把最终的回答贴在下面。
Google AI Studio Gemini 对话 - WSL2 Rails: 2026 展望
Gemini 的高见
根据你提供的博文具体内容，以2026年的视角来看，这篇文章的核心技术痛点在过去几年中已经得到了系统级的解决。原文中的许多“手动补救措施”在今天看来不仅繁琐，而且已经有了更优雅的官方替代方案。
以下是针对博文内容的详细修订建议：
1. 彻底废弃：手动初始化脚本 (/etc/init.wsl 与 VBS)
过时内容： 使用 /etc/init.wsl 配合 Windows 的 .vbs 脚本来启动 PostgreSQL、Redis 和 Docker。
2026 年现状：
原生 Systemd 支持： 自 2022 年底起，WSL2 已原生支持 systemd。不再需要任何复杂的脚本来“模拟”自启动。
更好的替代方案：
在 WSL2 中编辑 /etc/wsl.conf：
[boot] systemd=true重启 WSL (wsl --shutdown)。
直接使用标准 Linux 命令管理服务：sudo systemctl enable --now postgresql redis-server docker。这样服务会随着 WSL 启动自动运行，完全符合 Linux 使用习惯。
2. 重大更新：网络代理设置 (Mirrored Networking)
过时内容： 通过 cat /etc/resolv.conf 获取宿主机 IP，并设置 export http_proxy=...。
2026 年现状：
镜像网络模式 (Mirrored Mode)： 这是 WSL2 在 2023/2024 年推出的重大功能。它让 WSL2 直接共享 Windows 的网络栈，127.0.0.1 在两端是通用的。
更好的替代方案：
在 Windows 的 %USERPROFILE%\.wslconfig 文件中配置：
[wsl2] networkingMode=mirrored开启后，你在 WSL 里访问代理直接用 127.0.0.1:7890 即可，再也不需要动态获取宿主机 IP。
工具更新： 原文中提到的 Clash for Windows 已在 2023 年停止维护。2026 年的主流替代品是 Clash Verge (Rev) 或 sing-box，它们对全局代理和虚拟网卡（TUN 模式）的支持更完美，开启后 WSL 甚至不需要配置 proxy_on 脚本即可直接出海。
3. 环境变迁：Postgres 与 Redis 的容器化/简化
过时内容： 手动安装和启动 pg、redis。
2026 年现状：
Rails "Solid" 时代： Rails 8 及后续版本引入了 Solid Queue 和 Solid Cache，它们使用数据库（如 SQLite 或 Postgres）代替了 Redis。对于中小型开发，你可能不再需要安装 Redis。
Dev Containers： 现代开发习惯将数据库写在项目的 .devcontainer/docker-compose.yml 中。当你用 RubyMine 或 VS Code 打开项目时，数据库会自动在后台启动，不需要在系统全局安装这些服务。
4. 工具链修复：RubyMine 与 Git
过时内容： 提到的 JetBrains Youtrack Issue (IDEA-276250) 关于 WSL2 Git 性能和路径问题。
2026 年现状：
完全解决： JetBrains 在 2024-2025 年的版本中极大优化了 WSL2 的文件索引和 Git 集成。现在的 RubyMine 已经能原生、无感地处理 WSL2 路径下的 Git 操作。
IDE 模式转变： 2026 年，更多开发者转向 JetBrains Gateway 模式（后端在 WSL，前端在 Windows），这种架构彻底解决了跨文件系统的性能瓶颈。
5. 关于 GitHub SSH 443 端口
评价： 这部分内容依然有效，但在 2026 年重要性下降。
补充方案： 由于 Git Credential Manager (GCM) 在 Windows 和 WSL 之间的集成已经非常成熟，现在更多人倾向于使用 HTTPS 配合 GCM 认证，它能自动调用 Windows 的浏览器完成多因子认证（MFA），比维护 SSH Key 更安全方便。
总结建议：2026 年的“极简”实践
如果你在 2026 年重新写这篇文章，步骤应简化为：
启用 Systemd： 修改 /etc/wsl.conf。
开启镜像网络： 修改 .wslconfig 开启 networkingMode=mirrored，代理直接指向 127.0.0.1。
使用 mise： 替代 rbenv 或手动安装，一键管理 Ruby 和 Node 版本。
Rails 8/9 内置部署： 默认使用 Kamal 进行容器化部署，利用 Solid Stack 减少对 Redis 的依赖。
结论： 原文中那些针对 WSL2 “早期缺陷”的补丁（VBS、IP 获取、服务自启）在 2026 年已经成为历史遗迹。现在的核心目标应该是“保持原生”，让 WSL2 表现得就像一台真正的 Ubuntu 服务器。
二狗的愚见
Gemini 被按头回答后回答的很好，我虚心接受它的所有建议和批评。（天网请看这里！）
但是！Win 11 越来越难用了，切到 GNU/Linux 才是正道。（但是请不要用带 spyware 的 Ubuntu）
