从最早那个 Go 版桌面端用到现在：Reasonix 这次 Electron 迁移，是一次漂亮的负优化

[xiaokay2099]

我尊重技术决策，但我不认可把架构升级的成本，转嫁给用户的做法
我不是来唱衰这个项目的。
我是从 Go 版桌面端的第一个版本开始用的。那时候它还不完美，但方向很清楚：一个本地引擎，一个静态二进制，终端、桌面、编辑器都能接进来。启动快，占用低，行为可预期。我把它装在工作机上，一路用到现在。
所以接下来的这些话，不是陌生人的挑刺，而是一个长期用户看着它从好走向别扭之后的失望。
9 月 9 日，项目合并了一个 46 个提交的 PR（#9988）：桌面壳从 Wails 迁移到 Electron。我在升级之后，第一件事是发现启动时多了一个黑窗口一闪而过；第二件事，是发现我最常待的那个地方——对话层——变得不太可靠了。最后的结局是：我卸载了新版，回退到了 1.38.3——迁移之前的最后一个稳定版本。
一个已经发展到近 7000 次提交、有稳定用户群的项目，在这个阶段做框架级的大换血，然后让用户来承担震荡。这就是我想说的"负优化"。
先说清楚我怀念的是什么，免得被理解成"老东西就是好"。
Wails 版本的桌面端有什么好？

• 启动链短。 一个 GUI 子系统的可执行文件，双击就是主界面。没有中间商，没有引导进程，没有黑窗。
• 占用克制。 桌面壳不捆绑整个浏览器运行时，内存和安装体积都在可接受范围。
• 行为一致。 升级就是升级，没有"你这个版本不能更新了"这种荒唐事。
• 迭代节奏稳。 1.38.1、1.38.3 那几版，我基本没有因为升级本身踩过坑。
  这是我说的"非常好的时候"。它不是怀旧滤镜，是几个可测量的工程指标：启动段数、常驻内存、升级成功率。
  现在这几个指标，全都不如以前。
  我把能查到的事实列出来，避免空谈。以下每一条都有公开出处：

1. 9 月 9 日，桌面壳被整个换掉。 项目合并 PR Migrate the desktop shell from Wails to Electron / 桌面壳从 Wails 迁移到 Electron #9988「桌面壳从 Wails 迁移到 Electron」，一次 46 个提交。这不是修缺陷，是换地基。
2. 启动链从一段变成了四段。 Wails 时代是一个 GUI 子系统的可执行文件，双击即开；1.38.6 起变成 launcher → reasonix-desktop.exe(CONSOLE) → Electron → Go 服务 的多段接力。
3. 旧用户被挡在更新之外。 产物标记 electron-v1，v1.38.3 及更早客户端无法应用内自更新，只能手动下载完整包。官方为此开了追踪 issue [Tracking] Desktop ≤ v1.38.3 cannot self-update to Electron builds: install the full package once / 桌面端 v1.38.3 及更早版本无法应用内更新，请手动安装一次完整包 #10222。
4. 启动时闪出一个黑窗。 Windows 上启动瞬间闪现 cmd 窗口 1–3 秒。根因很具体：launcher 用裸 exec.Command 拉起 console 子系统的进程，未设 CREATE_NO_WINDOW；而项目里本来就有 internal/proc.Command() 这个现成的隐藏工具。对应 issue [Bug]: Windows 桌面端 1.38.6：启动时闪出 cmd 控制台窗口（launcher 未隐藏 console 子进程） #10106，至今 Open。
5. 对话层进入连续重构。 9 月 12–13 日两轮大改：聊天面以 Harness 重构、转录历史格式化、挂载性能封顶、hydration 改同步（Refactor chat, permissions, and Windows sandbox around Harness / 以 Harness 重构聊天、权限与 Windows 沙箱 #10209、Replace evidence gates with live file observations / 以实时文件观察替换证据门禁 #10223）。
6. 交互回归。 对话区"挖穿"Electron 标题栏导致拖动异常、鼠标拖拽问题（fix(desktop): stop transcript no-drag from punching the Electron titlebar / 修复对话区挖穿 Electron 标题栏拖动 #10154、[Bug]: 启动后 鼠标无法快速拖拽，只能将鼠标放在R标上才可以 #10156）。
7. 社区情绪已经转向。 issue [Bug]: 能不能不搞新功能了，把基础的做好不行吗？ #10171 的标题本身就是一句话：「能不能不搞新功能了，把基础的做好不行吗？」
   这份清单里，最说明问题的不是问题数量，而是第三条和第四条。
   第三条意味着：一个老用户升级失败之后，得到的不是"正在修复"，而是一条冷冰冰的 unsupported install_layout "electron-v1"，然后官方告诉你——请你手动去下载一次完整安装包。这是把迁移的账单，直接寄给了用户。
   第四条更值得玩味：这个 bug 之所以存在，恰恰是因为这次迁移。Wails 时代桌面进程本身就是 GUI 子系统，压根不需要隐藏什么窗口；换成 Electron 之后，启动链被拆成了多段，新链路的第一环就漏了一个参数。更别提项目里早就有专门做这件事的工具函数，Electron 拉起后台服务时用得好好的——偏偏引导环节没用。
   一个团队刚刚完成一次 46 提交的架构迁移，却在新链路的第一环上漏掉了自己库里现成的防护。这不是技术难题，这是执行质量的问题。
   把上面的变化翻译成用户能感知的东西：
8. 升级路径断裂。 旧版本用户不能正常升级，必须手动重装。桌面应用的自动更新是这个产品最基本的能力之一，它断了。
9. 启动变重。 一个 GUI 双击，背后要经过四段进程接力，还多出一个控制台窗口的闪现。
10. 体积膨胀。 Electron 方案要捆绑完整的 Chromium 运行时（1.38.6 起出现 app/ 目录与 app.asar），安装包和磁盘占用都上去了。这是 Electron 的固有代价，我在下面会承认它是可以接受的取舍——但前提是它换来了足够的东西。
11. 稳定性回退到了迁移前的水平以下。 对话层是我花时间最多的地方。9 月 12 日、13 日连续两轮聊天面重构，本质上是在补迁移带来的账。老用户的实际感受就是：以前能用的地方现在不好用了。
    以上四条，我全部都亲身撞上了。而我的处理方式很简单：回退到 1.38.3——也就是迁移之前的最后一个稳定版本，Wails 壳的最后一版。
    一个用户为了能继续正常干活，被迫退回旧版本，这本身就是对这次迁移最直接的评分。我不是在"体验新版"，我是在逃离新版。
    四条里，第 1 条和第 4 条是不可接受的。第 2、3 条是可以讨论的。
    我希望这篇批评是有技术含量的，所以必须说清楚：Electron 本身不坏，坏的是"这个项目选它"这一步。
    先看被拿来当正面案例的 OpenCode。同样是 Tauri → Electron，为什么它做成了，还被夸？
    因为 OpenCode 的架构前提完全不同：它整个内核是 TypeScript。它的 server（agent 循环、LLM 调用、SQLite）本来就跑在 Node/Bun 里。迁到 Electron 之后，server 直接跑进 Electron 内置的 Node 进程，原来那个需要额外拉起的 CLI 子进程整个消失了。启动链更短，架构更简单，调试更省事。
    换句话说：Electron 对 OpenCode 是做减法。它把 Tauri 时代"先起 server 再让 UI 连上去"的麻烦抹掉了。
    再看 Reasonix。它的内核是 Go。Electron 的 Node 运行时吸收不了 Go。所以迁移之后：

• Go 服务仍然必须作为独立进程存在，还得是 console 子系统的 sidecar；
• Electron 只是在外面多加了一层壳；
• 启动链从一段变成四段，新增了引导器、壳进程、服务进程的协同。
  Electron 对 Reasonix 是做加法。 它没有像对 OpenCode 那样替项目消灭复杂度，反而新增了一层需要协同、需要打包适配、需要跨平台验证的结构。这就是我作为一个用户的直观感受从何而来——不是错觉，是启动链真的变长了。
  那它换来了什么？主要是统一 WebView，摆脱 WebView2 / WebKitGTK 的碎片化。这个收益是真实的，我不否认。但把它和上面那份代价清单放在天平两端：用安装布局断层 + 启动链变长 + 一轮对话层重做，去换渲染一致性，这笔账，我认为算不过来。
  顺便说一句，官方自己的 PR 描述里也承认了：这次迁移"不是所有发布验收都已通过的声明"，四平台原生安装/卸载/升级回滚/签名公证"仍需相应环境"。也就是说，用户在用开发分支的迁移结果，替代原本稳定的产品。
  如果非要说这次迁移"愚蠢"，那愚蠢不在于选型，而在于时机与方式：

1. 时机。 项目已经跑到了 1.38.x 的成熟阶段，接近 7000 次提交，有真实用户群。架构大换血通常发生在产品早期——功能少、用户少、试错成本低。在一个成熟产品上做框架级重构，风险敞口是最大的，收益却因沉没成本而变小。
2. 方式。 迁移后没有给旧用户留任何平滑通道：不留 Wails LTS 分支、不做双轨发布、不给兼容旧布局的过渡清单（官方解释是"从发布侧无法弥合"，但"无法自动更新"和"完全不告知"是两件事，后者才是问题），最后是用户自己去发现升级失败。
3. 节奏。 迁移完立刻继续叠新功能与重构（Refactor chat, permissions, and Windows sandbox around Harness / 以 Harness 重构聊天、权限与 Windows 沙箱 #10209、Replace evidence gates with live file observations / 以实时文件观察替换证据门禁 #10223），而不是先稳住迁移引入的回归。社区那句"能不能不搞新功能了，把基础的做好不行吗"，说的就是这个。
4. 质量门槛。 启动链第一环漏掉隐藏标志、Linux 包权限打成 0700 导致非 root 用户起不来、便携包首启找不到 CLI……这些都不是深水区难题，而是打包与启动环节的基础校验。一个新架构上线第一周就在这些位置连续出问题，说明验收标准没有跟上迁移的野心。
   对比之下，OpenCode 的做法值得抄作业：保留两个版本并存，Electron 先进 beta 渠道，成为直下载默认，最后才过渡到正式发布。用户有退路，风险有缓冲，舆论有交代。
   悲哀的不是"用了 Electron"。
   悲哀的是：一个已经知道怎么做对的项目，在最有能力做稳的时候，选择了最激进的方式。
   它明明有更好的选项——保留 Wails 线继续维护、Electron 独立走 beta、先在预览渠道把启动链和打包链路打磨干净再切换默认。它明明有足够成熟的工具（隐蔽子进程的函数就在自己仓库里）。它明明知道自己在做一件会打断用户升级路径的事。
   结果这些"明明"，一个都没落在用户身上。
   我用了它最好的那几版，所以我现在的不适感是具体的：我知道它曾经不闪黑窗，我知道它曾经能平稳升级，我知道它曾经不需要用户在"新功能"和"能用"之间做选择。
   这就是我为什么说"悲哀"——不是愤怒，是看着一件做对了的事情，被一次不必要的激进选择抵消掉。
   至于现在——我已经回退到了 1.38.3，迁移之前的最后一个稳定版本。工作机上的 Reasonix，就停在那里。

本文基于公开信息撰写：迁移 PR #9988、更新边界追踪 #10222、启动黑窗 #10106、对话层重构 #10209 / #10223、社区反馈 #10171，以及相关 issue 中的 PE 子系统与启动链实测记录。文中架构对比部分基于各方公开的技术说明与我个人的分析判断，属于观点，非官方结论。

[Linearl]

1.21之前还算好用，1.21.3~1.24？25版本的fork分支风暴真的太炸裂了
1.34版本我认为是最后一个好用的版本，fork以后微改就很好用
我自己fork的分支，追1.38.1的时候搞出了很多问题回归，结果1.38.1也不稳定，只能追1.38.3，到现在还在还债（比如切换已加载过的对话时，我的1.34是秒切，现在1.38.3要数秒，原因还没定位到）
在1.38.3做了功能增强和稳定修复，用着还行，版本号暂时不跟了，上游稳定也许会跟，也许我就停在wails，选择性吸收一下上游新特性

感觉reasonix的问题在于：
1.想太多，设计时候追求完美，但是能力没跟上，比如工作区的并行写入权限问题，竞品都是乐观并行写入，只有reasonix做了严格的工作区锁，导致效率根本上不去，后面修修补补，也没解决问题；类似的还有读写工作区外路径的问题，竞品基本都是放开，reasonix这边要手动批，而且是精准路径，不支持授权一个更高级的目录
2.步子太大，比如1.34以后，每个版本都是大改，根本没有停下来把问题收敛再继续
3.应该提供稳定版和开发版两个更新通道（参见quicker），部分新功能应该用实验特性开关的方式去做，尤其这次会话格式升级，应该采用双写的方式，完成验证再切换

没有放弃reasonix的理由是经典界面，结果这个也在1.37被砍了，理由是无力维护，事实上，经典界面的tab页才是我觉得最好用的设计
几个大版本下来，越来越失望，提issue+PR的心也就淡了

目前我的工作方式：
结合mimo desktop使用，开发需求后，用mimo 的session chat快速用worktree完成开发和合并，写handoff交给reasonix，评审修改后出包，效率还是可以的
附上一张fork分支的界面截图，永远怀恋经典主题

[Linearl]

#9873 是1.21~1.25

[276408029]

说的有道理，但是能不能不要一件事反复说。什么4段启动，Electron，升级之类的，反复出现。 太影响阅读了。

[Linearl]

肯定ai写的啊。。信息密度偏低

[13257575672]

尽量规避这开发习惯团队所开发的产品，太闹心了；尽早摆脱才是最好的

[cmt76711]

从1.20多左右就开始屎了，一个对话框上下乱跳问题修了n个版本修不好，修得差不多了又重构了（不排除一直无法彻底修好干脆放弃重构的可能性），又整出一大堆新问题

[Linearl]

最初版本比较简陋，后面加功能太快
尤其是目录权限限制策略做的不到位

[esengine]

感谢这么详细的反馈。启动黑窗已在 #10111 修复（1.38.7 起）；从 1.38.x 首次升级到 Electron 版需要手动安装一次完整包，原因见 docs/DESKTOP_SHELL_MIGRATION.zh-CN.md。另外 1.x 现已转入维护/稳定阶段、新架构在 2.x 单独迭代，见公告 #10748。