做开发这几年我的硬盘里攒了一堆开发工具。从前端开发工具到C语言开发工具从AI开发工具到画架构图的软件每一样工具都是当年为了解决某个具体问题才折腾出来的。前阵子换电脑我把这些软件重新装了一遍顺手把配置、注意事项、踩过的坑都记了一份笔记。整理完发现信息量比想象中大干脆把笔记扩成这篇合集按实际使用场景把软件分类讲清楚给同样在搭建开发环境的同学一个参考。这篇文章不是软件地图更像一份我个人的使用日志适合刚工作的开发者照葫芦画瓢也适合老手从中挑几个还没试过的工具。1. 我选开发工具的三条底线1.1 为什么突然想整理这份软件合集起因很庸俗换电脑。旧机器上装了差不多四十多款开发相关的软件有些是项目需要装的有些是当年看别人推荐就装了的还有一些装上之后就再也没打开过。借着迁移环境的机会我把它们挨个过了一遍筛子留下真正会用到的卸载掉吃灰的同时把每款软件的安装方式、配置要点、在哪个环节会踩坑都重新验证了一遍。这个过程中最大的感受是开发工具这类软件不一定越贵越好也不一定越新越好关键看它跟你自己的工作流合不合拍。一个能解决你真实痛点的三流软件比十个躺在桌面上吃灰的所谓神器有用得多。所以这篇合集的核心不是“我推荐什么”而是“我为什么这样选”以及“这样选之后遇到了什么问题”。1.2 稳定优先选工具的第一指标很多开发者容易被“新功能”“炫酷界面”吸引我年轻的时候也一样。实际被坑过几次之后就学乖了。印象最深的是有一年做桌面端小工具用了某个刚流行起来的 UI 框架当时觉得 API 设计很现代结果项目做到一半框架连续两个迭代改了不兼容的接口我被迫停下业务需求去适配升级。从那以后我给自己定了一条规矩核心工具链选稳定版本新功能可以等一个版本迭代成熟了再说。怎么判断一个工具稳不稳定我的土办法是看三个信号。第一发布节奏是否规律频繁发版不一定好但半年没动静、issue 区长草的一般有问题第二破坏性变更的版本说明是否写得清楚第三社区里是不是已经有人总结出该工具在生产环境中的使用案例。满足这三条哪怕它界面朴素一点我都会优先考虑。1.3 能存成文件的工具优先级天然更高前几年画架构图我用在线网站当时觉得很方便拖拽就能出图。直到有一次项目答辩前那个平台突然改了收费规则免费用户导出图片强制带水印我整个人都懵了。那次之后我形成一个习惯**凡是能导出标准文件格式、能存到 Git 仓库里的工具优先级天然更高。**比如 Mermaid 这类用代码画图的方案虽然上手门槛比拖拽画图高一点但它产出的是一段文本跟着项目仓库走换电脑、换同事、换平台内容都不丢。再比如 draw.io 的桌面版文件就是.drawio或.xml拖进仓库里管理就行。这条底线尤其适合个人开发者。你没有公司的统一采购没有 IT 部门帮你维护授权你的每一份产出都应该能被自己长期持有。1.4 社区活跃度决定工具能走多远我选工具的第三条标准是看这个软件的社区环境和维护状态。一个软件哪怕眼下很好用如果作者已经停止维护那就相当于随时可能爆的雷。Windows 上很多老牌小工具就是这样当年的用户量很大后来作者不更新了系统和硬件一换代它就开始出各种莫名其妙的问题。所以我现在看到一个没听过名字的软件会先去它的官方仓库看看最后提交时间、issue 的回复效率、文档是否持续更新。社区活跃度虽然不代表软件本身一定好用但至少说明当你卡住的时候能找到人问能找到资料查也能期待它还适配未来的系统环境。2. AI 开发工具入局Codex 这类工具到底在帮我干什么2.1 Codex 不是什么代码补全说到 AI 开发工具身边朋友问最多的一个问题就是Codex 是什么软件它和 GitHub Copilot 有什么区别和那些带 AI 补全的 IDE 又有什么区别从我实际使用两个多月的感受来说Copilot 这类工具解决的是“这一行接下来怎么写”它在你写代码时给出下一个 token 的建议。而 Codex 做的事情更重它是跑在你本地终端里的一个AI 编程代理。你给它一个任务描述它会自己去读取项目文件、搜索调用关系、修改代码、运行命令甚至跑测试来验证自己的改动是不是对的。换句话说Copilot 是副驾驶帮你扶着方向盘Codex 更像一个实习生你把任务交代清楚它自己去查资料、动手改、汇报结果。当然这个实习生需要你盯着。它可能改对也可能改出你完全没见过的新问题。所以 AI 开发工具在我这里定位很明确加速重复劳动辅助信息检索但代码审查和决策这条线永远不会交给它。2.2 一次真实的 Codex 使用过程说个实际案例。上周我需要在一个老项目里找出某个 API 的全部调用位置并且确认每条调用链上有没有潜在的异常吞掉问题。这种活儿以前我都是用编辑器搜索一个个点开看效率很低。我跟 Codex 描述了一下需求项目是 Java 的入口在OrderService这个类里希望它列出所有调用placeOrder方法的地方并且检查这些调用点是否包含 try-catch 捕获、是否把异常信息打日志。Codex 先自己扫了一遍项目结构然后输出了一份调用链清单标注出每一处调用的文件和行号还顺带指出有两处 catch 里只写了e.printStackTrace()、没有业务日志这类问题在排查线上故障时极难追踪。整个过程中我需要做的就是给一个清晰的任务描述然后等它出报告。如果你也想试我总结出一个提示词模板按这个结构写基本不会跑偏项目语言[Java/Python/Go]目标代码在 [类名/文件路径]我希望你完成 [具体任务]输出时请标注 [文件:行号]并检查 [特定风险点]。这里有个坑要说清楚提示词越模糊Codex 发挥越不稳定。它不是你肚子里的蛔虫你不说你关心异常日志它默认就只给你一个调用列表。把约束条件写清楚它才能给你靠谱的结果。2.3 用 AI 开发工具必须守住的底线用 AI 开发工具时间久了你会发现它有两个明显弱点。第一是自信地编造内容。它遇到不确定的配置或者不存在的函数签名时有可能会生成一个看起来很像样、实际上根本不存在的东西。我之前让它修一个 npm 依赖问题它直接给我推荐了一个包名我在 npm 上搜了半天根本没这个包。所以不管它生成什么代码涉及依赖、API、版本号的信息我都会手动确认一遍。第二是上下文窗口有限。Codex 虽然能读取项目文件但真正特别大的仓库它也不可能全部记住。让它处理跨模块的大改动时最好把任务拆成几个小任务分步执行。一口气说“帮我改完整套权限系统”它大概率会漏掉一两个模块。守住这两条底线AI 开发工具就能成为很好的加速器守不住它就是一台 Bug 生成器。3. C 语言开发工具实测C-Free 5.0 的使用步骤与替代方案3.1 C-Free 5.0 在今天的定位很多从校园里走过来的开发者在初学 C 语言时都用过 C-Free这款国产 IDE 曾经以体量小、启动快、界面简洁而流行。今天再去看它网上能搜到的还是那款 5.0 版本到我录这篇文章的时候它已经有相当多年没有正式更新了默认界面也停留在很经典的 Windows 风格。那它现在还能不能用我的判断是分场景。如果你是为了应付课程设计、考试练习要跑的是单文件、几百行以内的 C 程序C-Free 5.0 完全够用安装包只有几十兆开箱即用不会像 VS Code 那样还要配插件。但如果你要写多文件的工程、要使用较新的 C 语言标准或者要在 Linux 上做交叉编译那它的天花板就很明显了。它默认带的编译器相对陈旧对新标准的支持并不好。3.2 从安装到跑通完整使用步骤如果你决定在 Windows 上试试 C-Free 5.0我梳理了一下完整步骤。安装包下载下来之后一路下一步安装就行注意安装路径里不要带中文和空格否则后面编译个别库的时候容易出现路径解析问题。安装完成后第一次启动软件会弹出一个工程向导。这里建议选“新建 C/C 源文件”而不是建工程练习小程序直接建文件更快。接下来是很容易踩坑的一步设置编译器路径。C-Free 5.0 允许你自己选择编译器常见的搭配是它自带的 MinGW或者你在别处安装的 Dev-C 编译器目录。如果新建文件后直接编译系统弹出“找不到编译器”你需要到菜单栏的“工具 → 选项 → 编译器设置”里把编译器目录指到实际的 MinGW 安装路径。指对了之后点一下工具栏上的绿色三角按钮代码就能编译运行。调试功能也可以用。在代码左侧行号区域点击设置断点然后按 F5 进入调试状态变量窗口会显示当前作用域的变量值。对初学者理解循环、指针这些东西单步调试的效果比看一百遍教程都强。3.3 使用之前要交代清楚的三个细节第一个细节是编码问题。C-Free 5.0 的老版本对中文注释的支持不太稳定如果代码里出现大量中文注释在部分系统区域设置下会显示为乱码甚至极端情况下编译报错。解决方式是把源文件另存为 UTF-8 编码或者在文件开头尽量少写中文注释或者干脆注释用英文。第二个细节是默认编译器的 C 语言标准偏老。如果你写for (int i 0; i n; i)这种 C99 风格的声明方式老编译器可能不认。这时需要检查一下编译器的参数设置里是否启用了-stdc99或-stdc11如果选项里没有说明这个版本的编译器支持有限建议直接换编译器而不是死磕。第三个细节是窗口布局恢复。C-Free 5.0 偶尔在异常退出后下次打开会丢窗口布局代码区和编译输出区叠在一起。解决办法是在菜单栏选择“窗口 → 恢复默认布局”一次就能调回来。这个现象遇到的人不少不熟悉的人还以为是系统坏了。3.4 替代方案怎么选如果你试完 C-Free 5.0 觉得不太够用或者想从一开始就接触更主流的工具链我列一个简单对比工具适合场景优点需要注意C-Free 5.0教学练习、快速跑小程序轻量、启动快、操作简单多年未更新标准支持偏老VS Code MinGW-w64日常 C 开发、写多文件工程轻量、可定制、社区插件多需要自己配置 task 和调试器Visual Studio CommunityWindows 桌面开发、C 大型工程功能全面、调试器强大安装包大重偏 WindowsDev-C 维护版学生练习、简化学习配置简单集成编译器界面和功能相对基础CLion专业 C/C 开发智能提示强跨平台收费内存占用偏高我个人现在的情况是Windows 上主力用 VS Code 配 MinGW-w64写小练习图省事时依然会开 C-Free 5.0。它虽然老旧但胜在不用配置、不弹更新、打开就写。工具这东西用顺手的才是自己的。4. 前端开发与微信小程序开发者工具配 less 编译的完整流程4.1 前端开发工具的日常组合我在前端开发工具上的选择还算主流编辑器用 VS Code配上 ESLint 和 Prettier 两个插件代码提交前用 Git 做版本管理。这个组合不算新潮但它稳定团队协作时换谁来都一样。ESLint 负责约束代码质量比如变量未定义、函数内重复声明这类低级错误保存的时候就能标红提示Prettier 负责格式化代码风格单引号还是双引号、末位分号要不要这些争吵在项目里消失。两个插件配合还有一个细节需要在 VS Code 的 settings.json 里把 Prettier 设为默认格式化器并把保存时自动格式化打开才能真正做到“保存即统一”。4.2 微信开发者工具开启 less 编译的配置做微信小程序开发的时候微信开发者工具是绕不开的。原生 WXSS 写样式语法上接近 CSS但缺少嵌套写法遇到复杂页面重复代码量大。我习惯用 less 来写。微信开发者工具其实是支持 less 编译的只是默认没开。打开项目根目录下的project.config.json在setting节点里加上这样一段{ setting: { useCompilerPlugins: [less] } }保存之后重启微信开发者工具稍等片刻项目里以.less结尾的文件就会被编译成对应的.wxss文件。从此你在样式目录里新建一个index.less写嵌套样式、变量、mixin 都行保存后.wxss文件会自动重新生成小程序运行加载的还是原生的.wxss。有个操作细节开启这个功能之前先把已有的手写.wxss文件备份一份。因为打开 less 编译后同名.less文件会接管样式输出之前手写的.wxss如果跟自动生成的逻辑有冲突容易被覆盖或者忽略样式就乱了。另外useCompilerPlugins是数组字段里面还可以加[less, sass]之类的值来同时支持多种预处理器但如果只是为了 less只填这一项就够。4.3 改完配置不生效我的排查链路有朋友照着配置写完之后发现.less文件不自动编译问我怎么办。我一般按下面这个链路排查。先看project.config.json的 JSON 格式是否正确多一个逗号、少一个引号都会导致整个文件失效再看setting节点是不是写到project节点外面去了或者跟已有配置合并时语法冲突。然后确认文件扩展名微信开发者工具识别的是.less后缀如果你建的是index.scss或者index.less.txt它当然不会编译。还要看项目根目录是否正确这个配置是在项目级project.config.json里不是小程序的页面级配置。如果以上都没问题那么大概率是缓存问题。把微信开发者工具完全退出在任务管理器里确认进程结束再重新打开项目。大多数情况下这一步就能解决。5. 画架构图与流程图五款软件的实测对比与最终推荐5.1 架构图和流程图是两类不同需求很多刚开始画图的朋友容易把架构图软件和流程图绘制软件混为一谈其实这是两类不同需求。软件架构图表达的是系统的静态结构有哪些模块、模块之间谁依赖谁、数据流向哪里、服务部署在什么位置。它强调的是“结构”所以绘图工具要方便拖拽组件、连线、标注边界。流程图表达的是动态过程某个业务从开始到结束经过了哪些步骤、在哪些节点有分支判断、异常情况下怎么流转。它强调的是“顺序”所以工具要方便快速画矩形、菱形、箭头最好还能自动排版。用同一个工具当然也行但如果你知道自己主要画哪种图选型侧重点就会很不一样。5.2 五款软件的横向对比我自己这几年用下来先后试过 ProcessOn、draw.io、Excalidraw、Visio后来开始用 Mermaid 这类代码化方案各有取舍。软件主要特点适合画什么体验感受draw.iodiagrams.net免费、可存文件、支持本地和 VS Code 插件架构图、UML、流程图功能最全默认样式朴素但够用ProcessOn在线协作、模板丰富流程图、思维导图、架构图国内访问方便部分高级功能要会员Excalidraw手绘风格、轻量快速草稿、示意图画出来好看但不适合严肃的软件架构图Visio微软老牌绘图软件企业级复杂架构图功能强大但偏重价格也偏高Mermaid代码绘图、文本格式流程图、时序图、状态图适合放进 Git 仓库版本管理友好用表格对比完你会发现没有一款是银弹。ProcessOn 在线协作确实方便但免费版有文件数量限制导出带水印Visio 在微软生态里很强但个人开发者花一个订阅费用只为了画图我有点肉疼。5.3 我最终留下的绘图组合经过一段时间的折腾我目前的绘图组合是日常架构图用 draw.io概念草图用 Excalidraw需要进仓库的图用 Mermaid。draw.io 我用了大概三年理由很简单免费、离线可用、文件格式开放而且支持 VS Code 插件。我画完图直接存到项目仓库的docs/architecture/目录下团队任何人都能打开修改不存在“这个图只有我电脑上有”的情况。Excalidraw 是用来画“不那么正式”的图的。比如跟同事交流一个交互思路、快速记录一个页面组件草图它那个手绘风格让人很放松大家看着没有距离感沟通效率反而高。Mermaid 则是最“硬核”的选择。写文档时用代码画时序图、流程图不用维护图片资源改起来也快。缺点也有复杂架构图用纯代码画会非常累嵌套层级一多改一个节点要找半天。所以我的原则是简单关系图用 Mermaid复杂多人协作用的图还是 draw.io 更顺手。6. 桌面开发与运维小工具Fody 的编译期魔法、Meld 与双机热备6.1 Fody把重复代码压进编译期的 .NET 开发工具.NET 开发圈子里有一类工具叫 IL weaving 工具最典型的就是 Fody。它的原理很直接在代码编译成 IL中间语言之后、生成最终程序集之前插入一段自定义的修改逻辑。利用这个时机可以自动往程序集里注入大量重复而机械的代码把你从枯燥的工作里解放出来。举个例子WPF 和 MVVM 开发里最烦的一件事就是实现INotifyPropertyChanged。传统写法是在每个属性的 setter 里手动调OnPropertyChanged一个类有十几个属性就要写十几段几乎一样的代码。装了PropertyChanged.Fody之后你只需要写public class Person { public string FirstName { get; set; } public string LastName { get; set; } public string FullName FirstName LastName; }编译生成的 IL 会自动帮你把属性变更通知逻辑注入进去而且FullName这种依赖其他属性的计算属性也会在源属性变化时自动通知。这已经不是我第一次感叹如果能早几年知道这个工具能少写多少无脑属性。使用步骤上先通过 NuGet 安装 Fody 和对应模块包然后在项目根目录添加FodyWeavers.xmlWeavers PropertyChanged/ /Weavers重新编译一次魔法就生效了。需要注意两点第一Fody 的模块很多用哪个模块就装哪个不要一次性全装第二开启后程序集会变大一点因为额外注入了代码这是正常的。如果你在调试时发现堆栈里出现你没写过的调用很可能是 Fody 注入的代码不是你的 Bug。6.2 Meld文件与目录对比的常青树日常开发里遇到“两个配置文件哪里不一样”“两个目录的内容差多少”这种需求太频繁了我常用的对比软件是 Meld。Meld 是一款跨平台的可视化文件与目录对比合并工具Linux 下尤其常见Windows 和 macOS 也有安装包。它的核心能力是三个文件对比、目录对比、版本控制集成。文件对比支持语法高亮左右两栏并排显示差异点改动一目了然目录对比可以递归列出两个目录下哪些文件新增、哪些修改、哪些删除还支持过滤掉编译产物。我最常用到的场景是对比两套配置文件。比如本地配置和测试环境配置差别很大但是凭肉眼翻根本看不出哪里不同用 Meld 打开两个文件差异直接高亮。还有一个技巧Meld 支持三向对比在做代码合并时A 版本、B 版本、基线版本三列对齐显示冲突解决比纯文本 diff 工具清晰得多。在 Linux 终端里懒得开图形界面的时候我也会先跑diff -rq dir1 dir2快速看有哪些文件不同再决定要不要用 Meld 深入比对。6.3 双机热备软件离个人开发有多远聊到双机热备软件不少个人开发者会觉得这个话题跟自己没关系。我一开始也这么想直到有一次我自己搭的一个内部服务在凌晨挂了业务完全停摆到第二天早上才意识到最怕的不是开发出错而是服务器宕机后没有任何兜底。双机热备的核心思路很简单两台机器一台主一台备主机正常运行提供服务备用机实时同步数据或状态当主机故障时备用机自动接管服务对外 IP 和端口不变用户几乎无感知。常见的实现方式包括虚拟 IP 漂移、心跳检测加资源接管像 Keepalived 搭配 HAProxy/Nginx 就是很经典的开源组合。对个人开发者来说如果你只是跑一个日访问量几百的小站一开始就上双机热备确实重了成本也不划算。我建议先把快照备份、进程守护、日志监控做好等你的服务真的不能中断时再去研究虚拟机上搭一套 Keepalived 做实验。理解它的原理之后再做选型会清晰很多。7. 银河麒麟系统下的开发环境apt、yum 与离线安装命令记录7.1 第一步永远是确认包管理家族这几年国产操作系统慢慢多起来了最典型的就是银河麒麟。很多开发者在上面装软件遇到困难一上来就照着 Ubuntu 的教程敲apt install结果发现命令不存在也有人照着 CentOS 的教程敲yum结果也没有。问题通常出在没搞清楚系统的包管理家族。银河麒麟的桌面版和服务器版都支持多种内核架构很多版本基于 Debian 体系包管理走apt但也存在基于 CentOS 体系的老版本包管理走yum或dnf。所以第一步永远不是执行安装命令而是先确认系统属于哪个体系。cat /etc/os-release查看输出里的ID和ID_LIKE字段就能快速判断。如果包含ubuntu或debian就用apt系列如果包含centos或rhel就用yum系列。用错命令不会报“系统不对”但你会发现软件源地址根本对不上装一个崩一个。7.2 常用开发工具的安装命令确认好包管理家族之后安装开发工具就顺理成章了。以 Debian 系为例更新软件源之后一条命令可以装齐一批基础开发工具sudo apt update sudo apt install build-essential git python3 python3-pipbuild-essential里包含 GCC 编译器、make 等构建工具是 C/C 开发的基础。另外我建议顺手装一下curl和wget后边下载脚本和工具包时经常用。装 Node.js 有一点要注意发行版自带的 node 版本往往偏旧。我的建议是用 nvm 装指定版本这样后续切换项目需要的 Node 版本也更灵活。curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash装完重启终端nvm install 20就能装到较新的 Node 版本。如果你在内网环境不方便访问 GitHub也可以用发行版自带的 nodejs 包先将就。如果系统自带的软件源下载速度不理想可以换成国内高校的开源镜像站比如清华大学的开源软件镜像站那里提供了 apt、pip、npm 等多个源的配置方法。把软件源指过去之后安装速度和稳定性都会明显改善。7.3 离线安装 .deb 遇到依赖缺失怎么办内网环境或者没网的环境下安装软件最常见的姿势是从其他机器下载.deb包拷过去用dpkg装sudo dpkg -i xxx.deb这个命令经常会在最后一步报一串依赖缺失错误。原因很简单.deb包安装时只负责把自己解压进去它依赖的其他库不会自动下载。解决方法是先放行手动安装再用包管理器自动修复依赖sudo apt-get -f install这条命令会检查当前系统里所有未满足的依赖关系把缺失的依赖自动装上。修复完之后再执行一次dpkg -i就能成功。这条链路我在银河麒麟上试过很多次几乎每次都能解决问题。还有一个不常被注意的点离线环境下如果连apt-get -f install也找不到依赖包说明那些依赖包本身也需要手动下载导入。这时候建议先在联网机器上把整个依赖树下载好用apt-get download配合dpkg -i批量安装比一个个去搜省事得多。最后再分享一个小习惯我每隔半年会整理一次工具清单把半年没打开过的软件标记出来要么卸载要么找替代。软件这行更新太快工具库长期不清理机器上就会堆一堆不再维护的旧版本。整理的过程也是复盘自己工作流的过程你会发现很多流程其实可以换一种更顺手的工具重新搭一遍。目前我这份清单里最常用的还是那几个——AI 开发工具辅助写代码VS Code 和微信开发者工具做前端draw.io 画架构图Meld 做文件对比银河麒麟上的 Linux 命令做服务端维护。另外如果你是个人开发者做出来的工具软件准备上架建议提前把源码整理好去申请软件著作权想系统补一遍计算机基础的话软件设计师的软考教材也比网上零散教程扎实备考用的中级真题做几套之后回头再选工具会更有底。你手里那套组合是什么欢迎在评论区聊聊。