干开发这行电脑里装上几十个工具太正常了。但我发现一个很有意思的现象身边很多同事不是没有工具而是不知道用什么工具。每次遇到一个问题先搜半天资料下载一堆试用版本最后真正好用的反而被淹没在收藏夹里。前阵子我给团队整理wiki顺手把平时查得最多的内容汇总成了一份附录名字就叫“附录 AB主流框架速查 工具与资源清单”。A部分是框架选型速查前端、后端、移动端一页纸看完主流方案B部分是工具与资源清单按使用场景把数据库、终端、调试、系统维护、AI工具全部归档。这份东西发出来后新同事照着搭环境老同事查工具、查命令反馈都不错。所以我把这份附录的整理思路、主体内容和实操经验完整展开希望能帮到同样被工具焦虑困扰的同行。1. 先说清楚这份附录到底在速查什么1.1 附录 A 和附录 B 的分工逻辑先说为什么叫“附录 AB”。框架速查和工具清单本质上都是“什么时候选什么、怎么用”的快速参考都属于查表型知识不适合写成大段的理论文章。框架决定项目骨架工具决定日常效率两者是开发者每天都会反复接触的东西。把框架和工具分开归档查询路径最短你在选型阶段翻附录A在实施落地阶段翻附录B避免混在一起翻半天找不到。我在整理时还定了一个规则表格里只放“选型结论”和“高频命令”不放长篇原理。比如前端框架那一页每个框架配两行话加一张表能在30秒内定位到候选方案。这样做的原因是附录的价值是“快速给答案”原理性内容应该留在对应的官方文档里。我对团队的要求是看附录确定候选方案后再去读官方文档不要反过来。1.2 这份附录能解决哪几类场景问题这份附录适用的场景不少我列几个实际验证过的给新人做环境搭建索引拿到新电脑后照着清单装工具装完在表格里打勾半天就能进入开发状态。给老人做技术决策备忘技术选型讨论时直接投影一页对照表不同候选方案的优缺点一目了然争论成本显著降低。给自己做重装系统的恢复清单重装电脑后所有工具、配置项、下载地址都在不用再凭记忆四处找安装包。给团队做知识沉淀避免每个人各自为政装一堆重复工具。比如数据库客户端有人用DBeaver、有人用Navicat、有人用DataGrip最后统一到DBeaver光这一项就少了很多沟通成本。我最早整理这份清单只是个人备忘录后来发现团队收益更大。索性把清单放进Git仓库标注了“最近核对日期”每次有人提交新工具就更新一行。半年下来这份文档就成了团队的“工具共识”有人问工具推荐直接甩链接节省大量重复解释时间。2. 附录 A主流框架速查表2.1 前端框架一张表看懂怎么选前端框架的选择很主观但我依然整理了一张“场景优先”的对照表不纠结谁强谁弱只回答“什么场景选什么”框架典型场景核心优势学习成本一句话建议React复杂中后台、大型SPA、组件生态生态最大、社区资料多中团队有React基础就选它别犹豫Vue中后台管理系统、中小型项目上手快、文档中文友好低快速交付首选Angular企业级大型应用、强规范团队一体化方案、依赖注入体系高适合长期维护、纪律严格的团队Svelte轻量页面、对包体积敏感编译期框架、运行时极小低小项目尝鲜不错生态偏小众Next.js内容型站点、SEO优化、全栈开发SSR/SSG、服务端组件中但凡要做SEO就选它NuxtVue生态下的同构应用Vue版SSR目录约定成熟中团队是Vue栈又需要SSR时选Nuxt选前端框架真正的坑不是选错而是中途换框架。我见过好几个项目写了两三个页面之后发现不顺手临时换框架成本高到离谱。后来我总结了一条经验超过三个人的团队优先选团队最熟的技术栈而不是最火的技术栈个人项目或内部小工具再考虑新框架。框架热度只能作为参考团队熟悉度才是第一决策因素。2.2 后端框架从单体到服务化后端框架我同样做了张表但多考虑了一个维度团队基础。很多框架性能固然好团队不会用线上迟早要出事。框架语言/生态核心优势建议场景Spring BootJava/Kotlin企业级稳定、Spring生态完整、微服务配套成熟中大型后台、企业级系统DjangoPython自带ORM和Admin、开发快快速原型、内容管理、内部系统FastAPIPython异步、自动生成OpenAPI文档、性能好数据API、AI服务、高并发IOFlaskPython轻量、灵活、扩展自由小服务、需要高度自定义的技术栈Express / NestJSNode.js生态大、前后端同语言BFF层、实时应用GinGo性能高、部署简单、并发好网关、微服务、中间件服务Actix-webRust极致性能、内存安全高并发网关、核心计算服务后端框架最容易踩坑的是异步模型没想清楚。FastAPI这类异步框架很迷人但团队如果不熟悉asyncio同步业务代码混进去很容易阻塞事件循环。我踩过这个坑某服务里有人在async函数里直接sleep三秒并发一上来所有请求全部排队线上立刻告警。所以我在速查表里特意加了一列“团队基础要求”提醒选型时别只看框架的纸面性能。2.3 移动端与桌面端框架移动端和桌面端框架我整理了一张更贴近实际工程选择的表重点标注了生态和体积这两个容易被忽略的指标框架平台优势注意点FlutteriOS/Android/桌面/Web自绘引擎、UI一致、性能好包体积偏大、动态化弱React NativeiOS/AndroidJS生态、热更新方案成熟复杂原生交互需要桥接uni-app小程序/H5/App一套代码多端运行国内小程序首选深度原生能力受限Kotlin MultiplatformiOS/Android共享业务逻辑、Kotlin统一生态还在成长ElectronWindows/macOS/Linux桌面应用生态大、社区方案全内存占用高、包很大TauriWindows/macOS/Linux用系统WebView、体积小、内存低兼容性细节多、生态较新一个小建议选移动端框架前先确认小程序的占比。做国内To C应用多半绕不开小程序uni-app或Taro这类多端框架能大幅减少重复开发。但如果只做专业AppFlutter在一致性和性能上优势更大。桌面端则相反工具型小应用选Tauri复杂重型应用选Electron中间地带尽量用已经上线的成熟方案不要在框架上做太多冒险。2.4 速查表的正确打开方式最后给这条附录的使用方法。首先不要背框架表也不要拿它当圣旨。正确用法是在需求明确后用表格做减法把不适合场景的候选删掉剩下两三个再做深度对比。其次每次选型结束后把最终结果回写到表格备注列记录下为什么选它、遇到了什么坑这份表格会越来越值钱。第三版本信息要定期更新我通常每季度花十分钟核对一次版本号避免同事查到过时的组合。这套机制跑了一年团队技术选型的效率确实提高了不少。3. 附录 B开发调试类工具清单3.1 数据库与缓存工具数据库工具是日常使用频率最高的工具类别。我按通用客户端、专用客户端、命令行三档来归档。通用客户端首推DBeaver开源免费支持绝大多数数据库。如果同时接触MySQL、PostgreSQL、Oracle、SQLite装一个就够了不需要每样都装专属客户端。但SQL Server用户建议配一个专用图形化工具SSMS功能最全适合Windows环境做管理Azure Data Studio跨平台、插件化适合写脚本和查数据两者分工明确。轻量数据库场景我一直在用dbx这类小巧工具。它的定位是快速打开、快速查询适合日常查看SQLite和临时库不像重型客户端那样启动慢、探针多。说一个实际经验数据库图形化工具连不上时很多不是服务器问题而是认证协议不匹配。比如MySQL 8默认的caching_sha2_password认证旧驱动会直接报错解决办法是把连接驱动升级到最新版或者在内网测试环境的连接参数里加上allowPublicKeyRetrievaltrue生产环境则优先选用更安全的连接方式。Redis连接工具以前默认推荐Another Redis Desktop Manager免费、跨平台、双击键名直接看类型和值日常排查问题很顺手。官方RedisInsight更侧重集群管理和性能分析适合集群规模较大的场景。不过最稳的还是命令行redis-cli我会在附录里附几条常用命令INFO memory看内存SCAN 0 COUNT 100代替KEYS扫描键避免生产环境阻塞。3.2 终端与远程连接远程连接工具这几年变化挺大。以前Xshell是标配现在免费且好用的选择多了不少。Tabby是我现在的主力终端。核心优势是跨平台、颜值高、可定制而且SSH、SFTP、串口都在同一个窗口里。对运维场景非常省事左边是会话树右边是终端SFTP面板还能直接拖文件不用再单独开一个软件。Windows自带的Windows Terminal加自带的OpenSSH也够用但会话管理还是弱一些适合习惯命令行到底的人。老牌的MobaXterm依然值得推荐尤其适合需要X11转发的场景。它自带的X Server可以免去单独装Xming的麻烦在Windows上跑远程Linux服务器的GUI程序很稳。Xshell/Xftp这对组合偏老派但可靠有些公司环境只允许这类工具所以附录里我仍然保留了一份授权说明Xshell针对个人使用免费公司商用需要授权别搞混。一个实操心得不要在终端里反复输密码尽量用密钥登录。生成命令是ssh-keygen -t ed25519 -C 备注然后把公钥追加到服务器~/.ssh/authorized_keys。服务器端顺手关掉密码登录前一定要先测试密钥可用不然把自己锁在外面就只能去机房了。3.3 调试、抓包与崩溃分析调试工具这栏C/C程序员离不开gdb。我的速查表里有几条高频命令操作gdb命令设置断点break main 或 break file.c:10开始运行run查看调用栈bt跳转执行next / step / finish查看变量print var 或 info locals监视变量变化watch var反汇编当前指令x/10i $pcgdb的核心技巧是“把调试脚本化”。先用gdb -batch -ex break main -ex run -ex bt -ex quit ./a.out跑一遍快速拿到崩溃栈真正复杂的问题再进交互模式。编译时记得加-g忘加的话符号表缺失gdb基本只能看汇编排查效率会低很多。程序崩溃后对应的对象不同工具也不同。分析Linux内核崩溃转储用的是crash工具配合kdump生成的vmcore文件常用命令包括bt、files、mount、kmem能快速定位内核态异常。应用层的core dump文件则用gdb加core文件直接分析执行gdb ./app core之后输入bt就能拿到当时的调用栈。这个区别很多人混用我用粗体标在了附录里。抓包工具分三层看Wireshark适合GUI环境看包、过滤协议tcpdump适合服务器上命令行抓包Fiddler或Charles适合抓取应用层的HTTP/HTTPS请求。线上偶发超时这种问题我的习惯是先tcpdump -i eth0 host 目标IP -w /tmp/xx.pcap把包抓下来拉回本地用Wireshark分析不要在服务器上装图形界面。另外tftp工具也很实用局域网设备刷固件、传配置文件时比scp更简单很多网络设备只认TFTP。Linux下用tftp-hpa或atftpWindows上可以用tftpd64快速搭一个服务端。移动端和Java工具链里jarsigner和bundletool也是开发调试常客。jarsigner用于给JAR签名老项目里经常要手动执行jarsigner -keystore key.jks -storepass 密码 app.jar 别名注意JDK版本更新后给APK签名时优先用apksigner替代jarsigner格式更清晰。bundletool是Android App Bundle的官方处理工具构建AAB后可以本地生成APKS并安装到设备测试bundletool build-apks --bundleapp.aab --outputapp.apks --ksxxx之后用bundletool install-apks --apksapp.apks直接装到设备。这比发到应用商店再下载测试包快得多。3.4 编译、转换与跨平台构建编译工具在清单里独立一节重点记录两件事命令和版本。交叉编译工具链是嵌入式开发必装。ARM开发时常见组合是arm-linux-gnueabihf-gcc和aarch64-linux-gnu-gcc。但交叉编译最容易踩的坑不是命令写错而是头文件和库版本不匹配。我吃过一次亏宿主机的工具链太新编译出的二进制传到目标板的rootfs上一运行就报GLIBC_2.29 not found。后来按目标板的系统版本重新下载对应工具链并指定--sysroot指向目标板rootfs才彻底解决。如果项目简单也可以直接静态编译-static一加依赖问题全绕开但体积会变大。Qt项目的命令行工具同样不能忽视。qmake负责生成Makefilecmake可以现代化构建windeployqt、macdeployqt这类工具负责把Qt依赖库打包到可执行目录省去客户机器缺DLL的尴尬。qtchooser可以切换多个Qt版本避免不同项目之间的环境冲突。做跨平台桌面UI的建议在附录里把这些命令都记下来配合CI运行能省很多手工打包时间。文本处理工具虽然不算编译但和开发流程紧密相关。我日常用到最频繁的是Python的中文分词工具jieba代码量极小import jieba print(jieba.lcut(保持热爱奔赴山海)) # 输出[保持, 热爱, , 奔赴, 山海]做搜索、标签、日志文本分析时这个比正则硬拆靠谱得多。jieba还支持自定义词典行业术语可以直接加进去而且内置TF-IDF、TextRank等关键词提取算法。这段代码我放在附录里每次需要分词时直接复制改两行就能用。4. 附录 B系统维护、硬件与效率工具清单4.1 U盘、分区与启动盘制作系统维护这个板块很多开发者平时用不到但一旦用到就是救命级别的工具。U盘启动盘制作Rufus是首选。它最大的好处是快、干净、能校验。写入Linux ISO时Rufus会询问使用ISO镜像模式还是DD模式这个选择很关键多数Linux发行版用ISO模式直接写入即可但某些特殊镜像和旧版UEFI环境只有DD模式写入才能正常启动。我通常的做法是先试ISO模式无法引导再用DD模式重写。还要注意分区类型新电脑UEFI环境选GPT老机器BIOS环境选MBR选错启动时直接黑屏或者提示找不到设备。分区工具各平台都有不错的选择。Windows上DiskGenius功能全可以无损调整分区大小、恢复误删文件、检测坏道Linux上GParted用于无损分区GNOME Disks命令行对应disks工具适合快速格式化和日常查看。我的经验是对存量磁盘做任何分区操作前先把分区表备份出来。GParted的备份分区表功能或者DiskGenius的备份分区表功能都行几十KB的文件关键时刻能救命。我会在附录备注里记录磁盘序列号、操作时间和结果形成简单的变更记录。清理工具这栏Windows上Dism是经典选择可以做系统镜像清理、更新清理、启动项管理比某些全家桶干净得多。配合系统自带的存储感知日常维护足够。别装来路不明的清理大师卸载都卸不干净这是踩过坑的教训。4.2 刷机、固件与量产这节是工具清单里最硬核的部分我给它在附录里加了一个醒目前缀高风险操作区。手机与嵌入式设备的系统维护常见工具包括fastboot、Odin、SP Flash Tool等。fastboot是Android设备最通用的底层工具能刷boot、recovery、system镜像联发科设备常用SP Flash Tool通过PC端强制刷机。家用路由器刷固件很多设备也支持TFTP方式刷写只需要在局域网里搭个TFTP服务端把固件文件名设置成设备期望的格式开机时设备自动下载固件并刷写。这些操作每一步都要看说明最怕的是刷写中断断电、拔线都会变砖。再说存储设备量产工具。U盘和SSD并不是坏了就扔。U盘用对应主控厂商的量产工具可以重新开卡把扩容盘恢复成真实容量、清理坏块、重新分区甚至可以模拟成USB-CDROM或本地磁盘。关键前提是先用芯片检测工具确认主控型号和闪存颗粒再去下载匹配的量产工具版本版本对不上工具根本识别不到设备。SSD量产比U盘更复杂。以常见的SM主控为例开卡通常需要短接主控进入ROM模式然后用量产工具读取颗粒信息、配置容量、写入固件。这个操作能救回一些掉盘的SSD但任何一步匹配错误都可能让盘彻底报废。我的建议是第一次玩量产用一块价值不高的盘练习一步一步截图记录不要拿有重要数据的盘做实验。量产前绝对要做数据备份因为开卡过程等价于重新格式化所有数据都会消失。Android ROM维护这块boot.img提取工具也绕不开。修改系统级定制前需要先提取原厂boot分区镜像。现在常用的是payload-dumper这类工具直接把OTA包里的payload.bin解析出boot.img或者用Magisk自带的安装修补一个文件功能选择boot.img后生成修补后的镜像再fastboot flash boot刷回去。这个流程用于系统维护和测试是常规操作但不意味着可以去折腾不该折腾的东西实践前先确认是否在设备支持范围内。顺带提醒一句有些魔改类工具比如修改CPU微码去解锁某些参数我是不推荐碰的。这类工具通常出处不明操作风险极大实际收益往往只是显示个名字或者超一点点频代价却是CPU直接变砖、数据全丢。工具清单里我会单独勾选一行不做名单把这些高风险项标记出来避免年轻同事靠好奇心驱动去踩坑。4.3 AI 与效率工具这两年工具清单里变化最大的就是AI工具的快速涌现。两年前AI还像尝鲜玩具现在已经是日常搭档。我每天的工作里至少三个环节被AI工具改写了写代码之前的方案搜索、写测试用例、还有读报错日志。这部分工具我在附录里单独开了一节按编程辅助、内容处理、自动化运维三类收纳。编程辅助工具主流方案是GitHub Copilot、Cursor、通义灵码等。我在清单里给每个工具标注了推荐场景Copilot在IDE里补全Cursor做多文件重构Claude Code适合长上下文分析。实际使用心得是AI生成代码不要直接粘贴至少要在脑子里过一遍看看有没有边界条件没覆盖。我见过AI生成的SQL里带了一行DELETE语句直接删了半张表幸好有备份。所以附录里加了一条铁律AI生成代码必须人工审查通过才允许合入。内容处理这边文本生成检测工具也常被问到。免费查AI率这类工具散落在各大网站和小程序里可以当作写作参考但别太较真检测准确率很不稳定。真要判断一篇文章的来源和可靠性最有效的还是人工核对关键事实和原文引用而不是依赖某个百分数。自动化运维和RPA工具很多团队已经用起来了。影刀这类RPA工具在电商、财务、客服场景里很常见但流程跑久了就会遇到升级迁移的问题从旧版本流程迁移到新平台时元素选择器会大量失效变量映射也会错。所谓代码迁移工具能自动化转换一部分内容但迁移后一定要做全量回归。我见过一次迁移后的流程把收款和退款两个操作的选择器搞反运行了两天才有人发现。这个教训写进清单任何自动化流程变更先小流量试跑一周确认稳定再全量。4.4 工具清单怎么维护才不废最后这部分是我最想分享的工具清单本身怎么维护。很多人整理工具清单往往整理完就扔在网盘里吃灰。我这里给一个跑通的办法先建一个目录把清单拆成多个Markdown文件按类别归档比如framework-checklist.md、tools-dev.md、tools-ops.md、tools-hardware.md。每一项记录固定字段工具名、用途、适用场景、版本链接、替代品、最近核对日期、备注。备注里一定写“我为什么用这个工具”和“踩坑记录”。再把整个目录放进Git仓库每次更新就是一个commit可以回滚。多人维护时谁新增的工具谁负责补全备注。固定节奏更新每季度花十五分钟核对一遍把不用的工具标成退役把新工具放进试用区。最后是那个最有价值的机制新人入职照清单装一遍装的过程中遇到的坑回填到备注。这个机制能让清单持续进化不会变成过时废纸。我见过最好的团队实践是把这份附录当作周会前五分钟的固定议题谁有新工具、谁踩了新坑直接更新进文档半年后这份文档就成了团队的私房技术库。5. 常见问题与排查技巧实录5.1 SSH连接慢且经常超时遇到SSH连服务器特别慢多半不是网络问题而是两端配置问题。在服务器端/etc/ssh/sshd_config里把UseDNS设为no、GSSAPIAuthentication设为no重启sshd后通常立竿见影。客户端这边如果本地装了多个代理插件也会导致连接变慢。排查思路是先ssh -vvv看详细日志看卡在哪一步再对症处理。这个经验我写在附录的SSH工具备注里每次同事遇到类似问题直接截图发过去比重新讲一遍快得多。5.2 图形化数据库工具报认证错误数据库工具连接MySQL 8报Public Key Retrieval is not allowed是典型的驱动版本和认证方式不匹配。低版本JDBC驱动不认识caching_sha2_password需要在连接串加allowPublicKeyRetrievaltrue和useSSLfalse。但是请注意关闭SSL和允许公钥检索都意味着连接安全等级下降内网测试环境可以用生产环境还是优先换支持新认证的驱动并开启SSL。这个问题在速查表里标红因为太常见了。5.3 Rufus制作的启动盘无法引导原因很集中按顺序排查第一分区表类型对不对UEFI要用GPTLegacy要用MBR第二Secure Boot是否关闭自制镜像大多没有签名不关Secure Boot会直接被拒第三写入模式选没选对某些发行版需要DD模式第四镜像校验是否通过下载过程中损坏的镜像怎么都引导不了。其中第四点最容易被忽略Rufus自带的校验功能是免费的不用白不用。5.4 交叉编译的程序在目标板跑不起来症状很典型./app: /lib/xxx/libm.so.6: version GLIBC_2.29 not found。这代表程序中某条依赖要求目标板系统的GLIBC版本比实际高而GLIBC又很难随便升级。对应的解决思路有两条一是用目标板系统自带的工具链或相同版本的交叉工具链重新编译二是改用静态编译-static之后依赖全打进去跟目标板系统版本脱钩。静态编译对普通C程序很有效但如果依赖了复杂动态库静态链接不一定成功这时候老老实实对齐sysroot。5.5 量产工具识别不到设备量产工具连U盘或SSD都识别不到先别着急换工具版本。常规排查顺序是确认主控型号和工具匹配性用芯片检测工具看一眼换一个USB 2.0接口试试量产工具对USB 3.0的兼容性有时反而差确认设备是不是进入了正确的模式比如SSD量产需要短接ROM引脚U盘需要按住主控特定引脚再插入最后才是换电脑、换系统、换工具版本。整体来看量产排查的核心是逐项验证每动一项就重新扫描一次设备别一次改一堆变量否则永远找不到问题点。原本写到这就可以收尾了但最后想再分享一个真实体会。整理这份附录AB最大的收获不是占满硬盘的工具本身而是强迫我把自己的技术工作流完整梳理了一遍。以前遇到问题我的第一反应是收藏等于会了结果是收藏夹越来越乱真到用时还是两眼一抹黑。现在但凡用过顺手的新工具我会当场花两分钟补进清单备注一句使用场景。下一次不管是自己重装电脑、带新人还是写技术方案这份清单都能帮我省下不止两小时。如果你也觉得自己的工具库一团乱不妨现在就花半小时打开一份Markdown建立自己的附录AB。半年后回头看你会感谢今天这个决定。