Windows 的确让人满意这个结论是我在折腾了大半天 Code 之后才意识到的。作为同时跨 Windows 和 Linux 两套环境干活的人我对这两样东西的日常感知完全不一样Windows 是那种极少让我停下来想“系统为什么卡了”的存在Code 却是那种我在一个 2 万 Stars 插件遇险前后反复横跳后开始有点烦的工具。这篇文章想聊的不是“谁把谁取代”这种老话而是具体说说Windows 哪些细节让我觉得真的省心Code 又是哪些细节一次次消耗我的耐心以及最后我是怎么调整用法、让这个组合重新回到“够用”的。1. 先说结论这次对比里Windows赢在了“无感”不知道你有没有这种经历用着一台配置普通的机器日常浏览器开十几个标签后台还挂着容器、虚拟机、微信偶尔还要导出视频Windows 依然能稳得像块石头。真正让我对它产生“满意”这种感觉的不是某个炫酷的新功能而是它几乎从不制造存在感。1.1 好系统是让人感觉不到它的存在Windows 这些年最明显的变化其实是把底层那堆杂事收拾得很彻底。拿睡眠和唤醒来说手动睡眠-唤醒几百次下来极少出现睡死、驱动掉链子、蓝牙鼠标连不上这种幺蛾子。要知道在很长一段时间里Windows 笔记本的睡眠唤醒和驱动管理都是被骂得最狠的现在能做成这样说明调度和电源策略是真的用了心。另一个让人舒服的点是外设兼容性。插个新的机械键盘、图形数位板、USB 声卡系统基本能在一分钟内把驱动装好极少需要我去官网翻驱动包。相比之下同一个外设在 Linux 下可能要对着文档改半天配置在 Code 这类工具里则是动不动“需要重新加载”。这种“即插即用”的无感体验才是日常满意度的大头。1.2 不同电脑、不同场景表现都稳定我在一台近几年配置的机器和一台相对老旧的上网本上都装了 Windows。老机器跑 Windows 当然做不到飞起但至少不会出现“打开设置界面都要转三圈”的情况。后台任务、系统更新、磁盘占用这些以前最容易拖慢系统的环节现在都被拆得很细更新和日常工作基本不会互相抢资源。这让我想到了一个很合适的比喻操作系统像是水电煤最佳状态是拧开水龙头就有水而不是每次都要检查水压。Code 呢更像是工作台上的电动工具——功能很多但你拿起它之前总会担心这次通电之后会不会突然抖一下。2. 让人失望的Code问题不是“不够强”而是“不稳定”坦白说吧Code 的功能密度和插件生态绝对是一流的。但“功能多”和“让人满意”是两件事。让我一遍遍感到失望的更多是它在高强度使用下的不确定性有时候好好的有时候莫名其妙变慢有时候更新完直接崩掉一个插件。2.1 编辑器这种工具最怕“不稳定”代码编辑器对开发者来说就像外科医生手里的手术刀你可以不够多功能但不能在该锋利的时候卷刃。Code 最大的问题恰恰是它经常“卷刃”。举一个我遇到的例子某次打开一个包含几千个文件的项目Code 启动后直接占了快两个 GB 内存CPU 时不时跳上 80%。一开始我以为是我自己开的东西太多但后来发现禁用某个文件监听相关的扩展之后占用直接降了几百 MB。这种问题最大的杀伤力不在于“变慢”本身而在于你很难定位——今天好用明天不好用同一个项目换个扩展版本又不一样完全没有稳定预期。2.2 跨平台一致性其实是“半幻觉”Windows 版本和 Linux 版本我都用整体逻辑一致但细节上各有各的别扭。在 Linux 下字体渲染和终端体验要自己折腾在 Windows 下某些扩展的路径处理、shell 集成、自动补全行为又和 Linux 不完全一样。表面上写着“跨平台一致”实际上每个平台都在偷偷给你添点小脾气。更难受的是远程开发。Code 的远程开发形态非常先进但网络稍微一波动或者服务器内存不足整个会话就会卡成幻灯片。那种“保存一个文件等三秒”的感觉真的会让人怀疑是不是回到了拨号上网的年代。这是工具本身的设计理念很好但实际体验被现实条件拖住后腿的典型场景。2.3 版本更新带来的“薛定谔”体验Code 的更新频率快这本身是好事但快带来的副作用是你永远不知道这次更新会带来什么。有段时间我日常工作流依赖的某个插件总是在更新后出问题每次更新完都要多花十几分钟处理兼容问题。这不像 Windows 那种“更新完就算了”的省心更像是在不断拆盲盒。2.4 插件生态金矿和垃圾场中间没有安检Code 的插件市场能让你找到几乎所有需要的工具但生态繁荣的另一面是质量两极分化得厉害。有的插件只有几百次的下载量但依赖特殊运行环境装上之后光初始化就要 5 秒。有的插件和另一个热门插件互相冲突直接让语言服务崩溃。我见过太多开发者在群里问“为什么代码提示突然没了”最后发现是某个插件更新把另一个插件顶掉了。我的体会是插件这东西装的时候爽排查的时候哭。每次觉得 Code 卡顿先把插件列表过一遍八成能解决问题。3. 一次具体的卡顿追踪问题到底出在编辑器还是我手上光说“不稳定”太抽象我挑一次完整的排查过程还原一下当时的思路。这可能是这篇文章里最有价值的部分因为卡顿类问题的排查思路比最终答案更通用。3.1 现象描述不只是慢是“越用越慢”某个项目进行到中期我打开编辑器时明显感觉启动速度变慢了。刚打开还能勉强操作但只要是打开一个大的 TypeScript 文件、或者切换文件比较频繁编辑器就会像是陷入沉思输入一个字符之后要等两秒才回显。更奇怪的是有时过一会儿自己好了有时重启一次又好了完全没有规律。那时候我第一反应是是不是系统也该清理了但 Windows 本身的 CPU 和内存占用看起来并不高就很迷惑。3.2 排查第一步关掉所有扩展重建基线我先禁用所有已安装的扩展重启编辑器发现启动速度立刻快了打开文件也顺了那个“越用越慢”的劲儿基本消失。这说明问题大概率出在扩展上而不是编辑器核心也不是系统的问题。于是我开始做二进制排查一次只启用一个扩展使用一段时间观察 CPU、内存和编辑流畅度确定是哪几个扩展在捣乱。不过光靠“感觉”不靠谱一定要用数据说话。我开了 Windows 自带资源监视器看编辑器的 CPU 和内存曲线再结合编辑器命令面板里的“开发者: 启动性能”信息找出启动阶段耗时异常的扩展名字。这一轮排查下来发现两个嫌疑最大的扩展一个是文件监听类的它会扫描项目里几乎所有文件另一个是某个大而全的集成工具包启用了很多我用不到的功能模块。3.3 找到本质原因问题出在“监听”和“索引”两个扩展的共性是它们都会遍历项目文件、建立索引并且会持续监听文件变化。当项目里包含大量生成文件、打包产物、图片资源时这种全量遍历带来的开销是巨大的。这就像是在一个堆满杂物的仓库里为了找一颗螺丝把整个仓库的货架都翻一遍还每隔几秒就再翻一遍。这一步让我明白了卡顿不一定是扩展本身写得多烂更多时候是它和你手头的项目结构不匹配。在文件多且杂的项目里全量监听就是性能杀手。Windows 上的文件系统事件机制本身没问题但是事件量一大加上多个扩展各自维护各自的索引CPU 就扛不住了。3.4 最后的修正把“范围”缩小找到原因之后我做了几个针对性调整把项目中完全不需要关心的目录比如打包输出目录、依赖目录、临时文件加入忽略列表关闭搜索索引对这些目录的扫描在编辑器的设置中把文件监听排除规则也同步配置一份再把那个大而全的集成工具包换成几个更轻量的独立扩展。调整之后再打开整个项目启动速度大幅提升切换文件时也不再出现明显的延迟。这次排查让我真正理解了一件事很多时候“Code 让人失望”其实是“没有调教好 Code”。它的默认配置是面向大众的但你的项目不是大众项目所以默认配置不一定适合你。Windows 在这方面的逻辑恰好相反——它的默认策略做得足够保守稳定你几乎不用调教它就能保持在一个可用的状态。4. 调整之后能救回多少体验一份可抄作业的优化清单经过几个月的折腾我现在对 Code 的抱怨少了很多不是因为 Code 变好了而是我找到了适合自己工作流的调法。这份清单不复杂但每一条都踩过坑复制过去大概率也能用只是要记得按自己项目的情况调整路径和规则。4.1 先把“看不见的活儿”减下来在全局设置里把那些没必要索引和监听的目录全部排除。下面这段配置是我日常在用的可以看出整段配置的语义就是“尽量少干活只处理真正需要处理的文件”。{ files.watcherExclude: { **/.git/objects/**: true, **/node_modules/**: true, **/dist/**: true, **/build/**: true, **/out/**: true, **/target/**: true }, search.exclude: { **/node_modules: true, **/dist: true, **/build: true }, files.exclude: { **/.git: true, **/node_modules: true } }这里面的逻辑是文件监听、全局搜索、资源管理器显示这三件事各自都要遍历文件系统每一条排除规则都会直接减少文件通知事件的数量。文件监听规则尤其重要因为有些编辑器在 Windows 上会通过轮询方式监听文件变化如果监听目录过大CPU 和磁盘 I/O 都会持续紧张。4.2 把扩展数量从“囤积”降级为“按需”我建议每过一个季度做一次扩展盘点长期不用的直接禁用功能重叠的只留一个大而全的扩展包尽量换成按需加载的独立扩展。很多人舍不得删扩展觉得“万一以后用到”但实际上扩展越多编辑器的启动时间越长、后台进程越多、出问题的概率指数级上升。把扩展控制在真正高频使用的那十几个体验会有质的提升。同时记得关闭工作区推荐的扩展自动安装提示不然协作项目一打开编辑器会频繁提醒你装这个装那个烦得很。{ extensions.ignoreRecommendations: true }4.3 远程开发场景的专项优化如果你也把 Code 当作远程开发客户端来用那么有几件事值得提前做好远程机器上关闭不必要的端口转发减少网络隧道数量把自动保存关掉改成手动保存避免每次编辑都触发一次远端写入大项目只在远程终端里执行构建和搜索不要在编辑器的全局搜索框里直接搜索整个仓库。这些优化不能说让远程开发飞起来但至少能把“卡顿”控制在让人能接受的范围内。注意远程开发卡顿时先检查远程机器上的内存和负载再看网络延迟最后才是本地编辑器的设置。很多时候是服务器资源不足不是 Code 的锅。4.4 给 Code 换上更“保守”的使用姿势最后一个建议比较反直觉如果你追求稳定别追着每日更新版跑尽量使用稳定版并且关掉自动更新改成手动确认更新。频繁更新的编辑器会给插件生态带来连锁反应你很难判断某次变慢是不是因为刚升级到某个小版本。我自己就是固定在一个版本上用几个月除非有明确需要的功能否则不轻易升级。这其实和 Windows 的更新策略是同一套逻辑——稳定优先功能其次。Windows 不会每个星期给你推新功能它更倾向于把已经给的东西打磨稳定这种节奏对生产工具来说反而是靠谱的。5. 我最后的选择不放弃 Code但也不再迷信它说了这么多失望的地方你可能会以为我已经把 Code 换掉了。其实没有我现在依然用它写大部分代码因为它的生态和跨平台协作能力确实没有对手。但我不再把 Code 当成“开箱即用、装完插件就完事”的工具而是把它当作一件需要定期保养的装备。5.1 调整预期比换工具更实际每一个工具都有它的性格Windows 的性格是稳定、克制、不折腾Code 的性格是开放、强大、但需要你花心思去约束它。如果你用 Code 觉得处处难受不一定是你不会用也不一定是 Code 真的垃圾更可能就是你和它的使用模式还没磨合好。我给自己的定位是把 Windows 当基础设施把 Code 当作“增强型终端”。沉重的本地编译、复杂的语言服务、大型项目索引我会尽量放到专门的构建环境或者完整 IDE 里去做Code 更多地承担跨平台快速编辑、简洁查看、远程开发入口这些角色。这样各司其职之后两边都变得让人满意得多。5.2 我踩过几次坑之后的个人体会如果要总结一句最真实的感受Windows 的“满意”是默认给的Code 的“满意”是自己挣来的。Windows 在系统层面把稳定性做到了默认值让你几乎感知不到它的存在Code 则把一切选项都交给你让你自由地配置但自由是有代价的——你必须为自己的每一项配置承担责任。以前我也觉得“工具不顺手就换”但后来发现换工具的成本远高于调教工具的成本。与其不断寻找一个万能满意的工具不如先用熟一个稳定好系统再看清一个高上限编辑器然后花点时间把真实需求和工作流磨合起来。说到底这套组合让我干活越来越不折腾Windows 在底下稳稳托住Code 在上头按我的规则运转。这种感觉不是“Wow”是一种很踏实的“够用”。而日常开发的幸福很多时候就是由这种“够用”拼出来的。
Windows 的确让人满意这个结论是我在折腾了大半天 Code 之后才意识到的。作为同时跨 Windows 和 Linux 两套环境干活的人我对这两样东西的日常感知完全不一样Windows 是那种极少让我停下来想“系统为什么卡了”的存在Code 却是那种我在一个 2 万 Stars 插件遇险前后反复横跳后开始有点烦的工具。这篇文章想聊的不是“谁把谁取代”这种老话而是具体说说Windows 哪些细节让我觉得真的省心Code 又是哪些细节一次次消耗我的耐心以及最后我是怎么调整用法、让这个组合重新回到“够用”的。1. 先说结论这次对比里Windows赢在了“无感”不知道你有没有这种经历用着一台配置普通的机器日常浏览器开十几个标签后台还挂着容器、虚拟机、微信偶尔还要导出视频Windows 依然能稳得像块石头。真正让我对它产生“满意”这种感觉的不是某个炫酷的新功能而是它几乎从不制造存在感。1.1 好系统是让人感觉不到它的存在Windows 这些年最明显的变化其实是把底层那堆杂事收拾得很彻底。拿睡眠和唤醒来说手动睡眠-唤醒几百次下来极少出现睡死、驱动掉链子、蓝牙鼠标连不上这种幺蛾子。要知道在很长一段时间里Windows 笔记本的睡眠唤醒和驱动管理都是被骂得最狠的现在能做成这样说明调度和电源策略是真的用了心。另一个让人舒服的点是外设兼容性。插个新的机械键盘、图形数位板、USB 声卡系统基本能在一分钟内把驱动装好极少需要我去官网翻驱动包。相比之下同一个外设在 Linux 下可能要对着文档改半天配置在 Code 这类工具里则是动不动“需要重新加载”。这种“即插即用”的无感体验才是日常满意度的大头。1.2 不同电脑、不同场景表现都稳定我在一台近几年配置的机器和一台相对老旧的上网本上都装了 Windows。老机器跑 Windows 当然做不到飞起但至少不会出现“打开设置界面都要转三圈”的情况。后台任务、系统更新、磁盘占用这些以前最容易拖慢系统的环节现在都被拆得很细更新和日常工作基本不会互相抢资源。这让我想到了一个很合适的比喻操作系统像是水电煤最佳状态是拧开水龙头就有水而不是每次都要检查水压。Code 呢更像是工作台上的电动工具——功能很多但你拿起它之前总会担心这次通电之后会不会突然抖一下。2. 让人失望的Code问题不是“不够强”而是“不稳定”坦白说吧Code 的功能密度和插件生态绝对是一流的。但“功能多”和“让人满意”是两件事。让我一遍遍感到失望的更多是它在高强度使用下的不确定性有时候好好的有时候莫名其妙变慢有时候更新完直接崩掉一个插件。2.1 编辑器这种工具最怕“不稳定”代码编辑器对开发者来说就像外科医生手里的手术刀你可以不够多功能但不能在该锋利的时候卷刃。Code 最大的问题恰恰是它经常“卷刃”。举一个我遇到的例子某次打开一个包含几千个文件的项目Code 启动后直接占了快两个 GB 内存CPU 时不时跳上 80%。一开始我以为是我自己开的东西太多但后来发现禁用某个文件监听相关的扩展之后占用直接降了几百 MB。这种问题最大的杀伤力不在于“变慢”本身而在于你很难定位——今天好用明天不好用同一个项目换个扩展版本又不一样完全没有稳定预期。2.2 跨平台一致性其实是“半幻觉”Windows 版本和 Linux 版本我都用整体逻辑一致但细节上各有各的别扭。在 Linux 下字体渲染和终端体验要自己折腾在 Windows 下某些扩展的路径处理、shell 集成、自动补全行为又和 Linux 不完全一样。表面上写着“跨平台一致”实际上每个平台都在偷偷给你添点小脾气。更难受的是远程开发。Code 的远程开发形态非常先进但网络稍微一波动或者服务器内存不足整个会话就会卡成幻灯片。那种“保存一个文件等三秒”的感觉真的会让人怀疑是不是回到了拨号上网的年代。这是工具本身的设计理念很好但实际体验被现实条件拖住后腿的典型场景。2.3 版本更新带来的“薛定谔”体验Code 的更新频率快这本身是好事但快带来的副作用是你永远不知道这次更新会带来什么。有段时间我日常工作流依赖的某个插件总是在更新后出问题每次更新完都要多花十几分钟处理兼容问题。这不像 Windows 那种“更新完就算了”的省心更像是在不断拆盲盒。2.4 插件生态金矿和垃圾场中间没有安检Code 的插件市场能让你找到几乎所有需要的工具但生态繁荣的另一面是质量两极分化得厉害。有的插件只有几百次的下载量但依赖特殊运行环境装上之后光初始化就要 5 秒。有的插件和另一个热门插件互相冲突直接让语言服务崩溃。我见过太多开发者在群里问“为什么代码提示突然没了”最后发现是某个插件更新把另一个插件顶掉了。我的体会是插件这东西装的时候爽排查的时候哭。每次觉得 Code 卡顿先把插件列表过一遍八成能解决问题。3. 一次具体的卡顿追踪问题到底出在编辑器还是我手上光说“不稳定”太抽象我挑一次完整的排查过程还原一下当时的思路。这可能是这篇文章里最有价值的部分因为卡顿类问题的排查思路比最终答案更通用。3.1 现象描述不只是慢是“越用越慢”某个项目进行到中期我打开编辑器时明显感觉启动速度变慢了。刚打开还能勉强操作但只要是打开一个大的 TypeScript 文件、或者切换文件比较频繁编辑器就会像是陷入沉思输入一个字符之后要等两秒才回显。更奇怪的是有时过一会儿自己好了有时重启一次又好了完全没有规律。那时候我第一反应是是不是系统也该清理了但 Windows 本身的 CPU 和内存占用看起来并不高就很迷惑。3.2 排查第一步关掉所有扩展重建基线我先禁用所有已安装的扩展重启编辑器发现启动速度立刻快了打开文件也顺了那个“越用越慢”的劲儿基本消失。这说明问题大概率出在扩展上而不是编辑器核心也不是系统的问题。于是我开始做二进制排查一次只启用一个扩展使用一段时间观察 CPU、内存和编辑流畅度确定是哪几个扩展在捣乱。不过光靠“感觉”不靠谱一定要用数据说话。我开了 Windows 自带资源监视器看编辑器的 CPU 和内存曲线再结合编辑器命令面板里的“开发者: 启动性能”信息找出启动阶段耗时异常的扩展名字。这一轮排查下来发现两个嫌疑最大的扩展一个是文件监听类的它会扫描项目里几乎所有文件另一个是某个大而全的集成工具包启用了很多我用不到的功能模块。3.3 找到本质原因问题出在“监听”和“索引”两个扩展的共性是它们都会遍历项目文件、建立索引并且会持续监听文件变化。当项目里包含大量生成文件、打包产物、图片资源时这种全量遍历带来的开销是巨大的。这就像是在一个堆满杂物的仓库里为了找一颗螺丝把整个仓库的货架都翻一遍还每隔几秒就再翻一遍。这一步让我明白了卡顿不一定是扩展本身写得多烂更多时候是它和你手头的项目结构不匹配。在文件多且杂的项目里全量监听就是性能杀手。Windows 上的文件系统事件机制本身没问题但是事件量一大加上多个扩展各自维护各自的索引CPU 就扛不住了。3.4 最后的修正把“范围”缩小找到原因之后我做了几个针对性调整把项目中完全不需要关心的目录比如打包输出目录、依赖目录、临时文件加入忽略列表关闭搜索索引对这些目录的扫描在编辑器的设置中把文件监听排除规则也同步配置一份再把那个大而全的集成工具包换成几个更轻量的独立扩展。调整之后再打开整个项目启动速度大幅提升切换文件时也不再出现明显的延迟。这次排查让我真正理解了一件事很多时候“Code 让人失望”其实是“没有调教好 Code”。它的默认配置是面向大众的但你的项目不是大众项目所以默认配置不一定适合你。Windows 在这方面的逻辑恰好相反——它的默认策略做得足够保守稳定你几乎不用调教它就能保持在一个可用的状态。4. 调整之后能救回多少体验一份可抄作业的优化清单经过几个月的折腾我现在对 Code 的抱怨少了很多不是因为 Code 变好了而是我找到了适合自己工作流的调法。这份清单不复杂但每一条都踩过坑复制过去大概率也能用只是要记得按自己项目的情况调整路径和规则。4.1 先把“看不见的活儿”减下来在全局设置里把那些没必要索引和监听的目录全部排除。下面这段配置是我日常在用的可以看出整段配置的语义就是“尽量少干活只处理真正需要处理的文件”。{ files.watcherExclude: { **/.git/objects/**: true, **/node_modules/**: true, **/dist/**: true, **/build/**: true, **/out/**: true, **/target/**: true }, search.exclude: { **/node_modules: true, **/dist: true, **/build: true }, files.exclude: { **/.git: true, **/node_modules: true } }这里面的逻辑是文件监听、全局搜索、资源管理器显示这三件事各自都要遍历文件系统每一条排除规则都会直接减少文件通知事件的数量。文件监听规则尤其重要因为有些编辑器在 Windows 上会通过轮询方式监听文件变化如果监听目录过大CPU 和磁盘 I/O 都会持续紧张。4.2 把扩展数量从“囤积”降级为“按需”我建议每过一个季度做一次扩展盘点长期不用的直接禁用功能重叠的只留一个大而全的扩展包尽量换成按需加载的独立扩展。很多人舍不得删扩展觉得“万一以后用到”但实际上扩展越多编辑器的启动时间越长、后台进程越多、出问题的概率指数级上升。把扩展控制在真正高频使用的那十几个体验会有质的提升。同时记得关闭工作区推荐的扩展自动安装提示不然协作项目一打开编辑器会频繁提醒你装这个装那个烦得很。{ extensions.ignoreRecommendations: true }4.3 远程开发场景的专项优化如果你也把 Code 当作远程开发客户端来用那么有几件事值得提前做好远程机器上关闭不必要的端口转发减少网络隧道数量把自动保存关掉改成手动保存避免每次编辑都触发一次远端写入大项目只在远程终端里执行构建和搜索不要在编辑器的全局搜索框里直接搜索整个仓库。这些优化不能说让远程开发飞起来但至少能把“卡顿”控制在让人能接受的范围内。注意远程开发卡顿时先检查远程机器上的内存和负载再看网络延迟最后才是本地编辑器的设置。很多时候是服务器资源不足不是 Code 的锅。4.4 给 Code 换上更“保守”的使用姿势最后一个建议比较反直觉如果你追求稳定别追着每日更新版跑尽量使用稳定版并且关掉自动更新改成手动确认更新。频繁更新的编辑器会给插件生态带来连锁反应你很难判断某次变慢是不是因为刚升级到某个小版本。我自己就是固定在一个版本上用几个月除非有明确需要的功能否则不轻易升级。这其实和 Windows 的更新策略是同一套逻辑——稳定优先功能其次。Windows 不会每个星期给你推新功能它更倾向于把已经给的东西打磨稳定这种节奏对生产工具来说反而是靠谱的。5. 我最后的选择不放弃 Code但也不再迷信它说了这么多失望的地方你可能会以为我已经把 Code 换掉了。其实没有我现在依然用它写大部分代码因为它的生态和跨平台协作能力确实没有对手。但我不再把 Code 当成“开箱即用、装完插件就完事”的工具而是把它当作一件需要定期保养的装备。5.1 调整预期比换工具更实际每一个工具都有它的性格Windows 的性格是稳定、克制、不折腾Code 的性格是开放、强大、但需要你花心思去约束它。如果你用 Code 觉得处处难受不一定是你不会用也不一定是 Code 真的垃圾更可能就是你和它的使用模式还没磨合好。我给自己的定位是把 Windows 当基础设施把 Code 当作“增强型终端”。沉重的本地编译、复杂的语言服务、大型项目索引我会尽量放到专门的构建环境或者完整 IDE 里去做Code 更多地承担跨平台快速编辑、简洁查看、远程开发入口这些角色。这样各司其职之后两边都变得让人满意得多。5.2 我踩过几次坑之后的个人体会如果要总结一句最真实的感受Windows 的“满意”是默认给的Code 的“满意”是自己挣来的。Windows 在系统层面把稳定性做到了默认值让你几乎感知不到它的存在Code 则把一切选项都交给你让你自由地配置但自由是有代价的——你必须为自己的每一项配置承担责任。以前我也觉得“工具不顺手就换”但后来发现换工具的成本远高于调教工具的成本。与其不断寻找一个万能满意的工具不如先用熟一个稳定好系统再看清一个高上限编辑器然后花点时间把真实需求和工作流磨合起来。说到底这套组合让我干活越来越不折腾Windows 在底下稳稳托住Code 在上头按我的规则运转。这种感觉不是“Wow”是一种很踏实的“够用”。而日常开发的幸福很多时候就是由这种“够用”拼出来的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
