附录这种东西放在书里经常是被翻得最狠的章节。正文章节你可能会跳着看但主流框架速查和工具与资源清单这两块几乎所有人都会反复回来查。我这次整理的内容就是把团队里新人常问的我这个场景该选哪个框架这个工具到底有没有更好的替代这类问题一次性汇总成一份可以直接抄作业的清单。无论是刚转行做开发的小白还是带项目做技术选型的负责人都能从这份速查里拿到能用的东西——框架不是越多越好工具也不是越新越好关键是知道每一类里哪几个是经过验证的、什么时候用哪个顺手。1. 这个附录的定位速查不是教程先说清楚一个原则。附录 A 和附录 B 本质上是一份记忆外挂不是入门教材。我不打算在文章里把某个框架的安装步骤、配置手册再抄一遍那是官方文档的活这份东西要解决的是我记得有这么个东西但具体叫什么、用在什么场景、和另一个有什么差异的即时需求。所以我在设计这份速查时坚持三个标准每类问题只列真正主流、还在持续迭代、社区活跃度高的选项不搞大而全的考古列表。每条都带上什么时候选它、什么时候别选它的判断维度而不是只写它是一个框架这种废话。工具部分按使用频率排序优先讲每天都要打开的东西再讲特定场景才用的专项工具。我见过太多人收藏了几百个工具推荐帖真到干活的时候还是只会用最熟的那两三个。清单的价值不在于收藏在于能不能在关键时刻想起原来这个场景有专门的家伙。这也是我把附录拆成 A框架和 B工具两部分的原因——框架是建筑的骨架工具是手里的起子两者解决的问题完全不同。2. 主流框架速查按场景整理的选型参考框架部分的整理思路不是按语言罗列而是按你要干什么事来分组。同样是写后端三个人用的可能是三种完全不同的框架但它们各自解决的是不一样的痛点。2.1 后端框架JVM、Python、Node 与 Go 四条主线后端框架是选型最纠结的地方因为语言本身没有绝对优劣只有场景匹配度。下面这四组是我在实际项目中见到最多、也在真实生产环境里跑过的。框架语言典型场景上手成本一句话评价Spring Boot / Spring CloudJava企业级中后台、微服务、银行/政务类系统高生态最全招人最容易但启动重、学习曲线陡DjangoPython管理后台、内容站、快速交付的全栈服务低自带 Admin、ORM、迁移机制文档全面FastAPIPythonAPI 服务、AI 推理服务、实时数据接口低自动生成 OpenAPI 文档异步支持天然FlaskPython轻量 API、内部小服务、学习练手极低灵活但要自己拼组件属于半成品框架NestJSNode.js / TypeScript中大型业务后端、BFF 层中模块化思路接近 Spring适合 TS 团队Express / KoaNode.js简单 API、网关、胶水服务低生态广但需要自己约束结构GinGo高性能 API、网关、云原生组件中性能出色部署产物单文件协程友好我自己的经验是如果团队都是 Java 背景、项目要做五年以上的长期演进老老实实选 Spring Boot 全家桶周边资料和招人成本都能兜底。如果项目节奏快、团队小FastAPI 或 Django 能把后端开发效率拉高一大截特别是你还要顺带做数据处理或对接 AI 模型的时候。Node 系和 Go 系更多看团队技能栈前端团队做 BFF 用 NestJS 很顺运维基础设施类的服务用 Gin 会轻松很多。选型还要顺带考虑 ORM因为框架只是骨架数据访问层才是天天打交道的地方。Java 里 MyBatis-Plus 在国内用得非常普遍SQL 可控性好Python 生态里 SQLAlchemy 是事实标准Django 则自带 ORMGo 的 GORM 用起来最省事。这部分在速查里我会单独列一行备注提醒新手别把 ORM 和框架混为一谈。2.2 前端与跨端框架React、Vue 双雄和跨端三剑客前端框架的格局这几年稳定多了主流就是 React 和 Vue 两派Angular 在特定企业场景还有市场份额。速查里不需要把每个衍生库都列一遍真正要记的是下面这张表。框架定位典型配套适合场景ReactUI 库Next.js、Redux/Zustand、React Query中大型 SPA、需要生态灵活度VueUI 框架Nuxt、Pinia、Vite中后台、中小型项目、上手快Angular完整框架RxJS、Angular CLI企业级规范统一、大型团队Flutter跨端Dart、自绘引擎iOS/Android 高度一致性的 UIReact Native跨端基于 React 生态已有 React 经验的团队uni-app跨端国内小程序全家桶一套代码发小程序 App前端选择上我最常给出的建议是如果团队没有历史包袱Vue 对中小团队和个人开发者是最友好的中文资料多Vite 加持下的开发体验很顺。如果要做大型复杂应用、需要大量第三方库支撑React 生态的天花板更高React Query、Zustand 这些组合拳能省很多事。跨端项目我吃过不少苦头结论很朴素——UI 复杂度高的选 Flutter业务逻辑为主的选 React Native要覆盖微信小程序就基本只能用 uni-app。2.3 中间件、大数据与 AI 框架基础设施层面的速查框架不只是应用层的事。中间件和大数据组件同样需要速查尤其对刚接触分布式系统的人来说Redis、Kafka、Spark 这些名字很容易记混但它们的定位差异其实非常清晰。缓存与存储Redis 一骑绝尘缓存、分布式锁、简单队列都能做Memcached 现在用得少了只有极致纯缓存场景还有价值。消息队列Kafka 吞吐量大、持久化强适合日志、事件流和削峰填谷RabbitMQ 路由灵活适合业务消息和 RPC阿里系项目里 RocketMQ 的本地事务消息能力很常用。大数据计算Spark 做批处理和离线分析是主力Flink 做实时流处理基本没有对手。选型时记住一个简单判断——数据是一次性算完还是持续不断在算前者 Spark后者 Flink。分布式框架Spring Cloud Alibaba 是国内微服务的常见落地Dubbo 在做内部二进制 RPC 时性能优势明显。AI 训练框架PyTorch 现在是学术界和工业界事实标准TensorFlow 在特定部署场景仍有存量Transformers 库则成了大模型时代的公共底座。这一层框架的速查需要特别标注生态成熟度和运维成本因为中间件选型错了后期迁移成本比应用框架大得多。我在附录里会给每个中间件补一行单机学习成本/集群运维成本的标注方便在选型阶段就把隐性成本算进去。3. 工具与资源清单按使用频率排序的私房清单工具清单我整理了很长时间。网上推荐工具的文章极多但大部分是堆名字。我自己用的标准很简单装机之后会主动打开、出问题时会第一时间想起的才算工具下载完吃灰的不算。3.1 终端、SSH 与远程开发工具终端是开发者的阵地这块值得仔细配置。跨平台首推 Tabby颜值在线、自带 SSH/SFTP 会话保存、支持分组和主题同步Windows、macOS、Linux 通吃我用了快三年没有换过。Windows 用户还把 Windows Terminal 当作基座配合 WSL 相当舒适不过它的 SSH 能力弱一些远程重度操作用 Tabby 更顺手。Tabby跨平台、开源SSH/SFTP 内置配置可同步MobaXtermWindows 上会话管理极强自带 X server 和端口转发Xshell老牌工具个人家庭版免费批量会话管理成熟Termius多端同步做得最好手机上也能连服务器应急VS Code Remote-SSH适合直接用编辑器改代码的场景调试体验接近本地开发远程登录的底子是密钥认证。我强烈建议把密码登录换掉生成密钥的效率并不低ssh-keygen -t ed25519 -C your-name ssh-copy-id usertarget-host第一个命令生成密钥对第二个把公钥拷到服务器之后登录就不需要输密码了。换服务器排查问题时加上-vvv参数能看到全部握手过程很多 连不上 的诡异问题都能据此定位。3.2 数据库与缓存客户端数据库客户端是每天必开的工具我的原则是图形化为主、命令行兜底。DBeaver 是我用过最省心的免费开源方案MySQL、PostgreSQL、Oracle、SQLite 一网打尽还能直接看 ER 图DataGrip 适合 JetBrains 全家桶用户快捷键和补全体验一致但需要商业授权Navicat 在国内团队覆盖率最高功能全面同样需要购买授权。SQL Server 用户直接用官方 SSMS 就行不用折腾第三方。PostgreSQL 轻量操作也可以用 pgAdmin虽然界面老旧但稳定可靠。命令行工具属于应急底牌。服务器上没图形界面、排查慢查询、批量导数据时mysql、psql、redis-cli才是真正可靠的东西。Redis 的图形客户端我目前留下的是 RedisInsight官方出品、支持集群模式和慢查询分析另一个轻量的 Another Redis Desktop Manager 也够用胜在打开快、占内存小。3.3 调试、抓包与性能排查工具这一类工具平时用得少但一旦用到就是救命的。C/C 调试离不开 GDB我常用的命令无非bt查看调用栈、b下断点、p打印变量、watch监视变量变化。调试前记得编译加-g -O0否则符号信息和行号不完整GDB 使不上劲。内核崩溃转储可以配合crash工具解析这是排查内核 hang 和死锁场景下的核心手段。内存问题用 Valgrind性能热点用perf进程状态用top/strace这些命令构成了 Linux 排障的基本功。网络抓包首选 Wireshark它的过滤器语法值得花半小时系统学一遍比如ip.addr 192.168.1.2 tcp.port 443比点鼠标看包高效太多。接口调试工具Postman 是祖传选择但国内团队现在用 Apifox 的越来越多因为它把接口文档、抓包、Mock、压测都揉在了一个工具里前后端协作很省事。如果追求轻量和 Git 原生流程Bruno 这类新生工具也值得关注。3.4 构建、刷机、量产与硬件工具这部分是我特意加进去的因为很多开发者的工作不只是写应用还要碰车机、路由器、嵌入式板卡甚至存储主控。U 盘启动盘第一选择是 Rufus简单明了、速度快刷安卓设备或调试车机系统Google platform-tools 里的 adb 就是万能解码器配合 scrcpy 还能直接把手机/车机屏幕投到电脑上操作。应用分发场景里Google Play 上架的 AAB 格式要用 bundletool 拆成 apks 再装到设备上验证这条容易忘。量产工具和固件工具要单独说一句SSD 主控、U 盘主控的量产工具比如常见的 SM2258XT、YS9082 平台来源只有一个可靠渠道——主控厂商或板卡厂商的官方通道。网上流传的免费版魔改版往往伴随着降级、锁盘甚至数据损坏风险我在帖子里建议只从官方渠道拿。类似地CPU 微码修改工具如 CoffeeTime属于小众超频玩法能让你解锁一些出厂限制但也可能让硬件失去保修甚至变砖玩之前必须能接受这个代价。嵌入式开发场景里交叉编译工具链和 Qt 命令行工具是高频刚需。工具链版本尽量和目标平台的内核版本对齐否则编出来的库运行时容易报 GLIBC 版本不兼容。网络引导和固件烧写阶段会用到 TFTP 工具这是嵌入式调试的老朋友配置时记得注意服务端根目录和文件权限最容易出问题的地方往往就是这两处。3.5 AI 辅助与效率工具AI 编程助手现在已经是真实生产力不再是尝鲜玩具。Copilot、Cursor、通义灵码、CodeGeeX 这些工具我在团队里都有人用实际效果相差不太大关键是让 AI 看到足够的上下文——把相关文件、报错信息、预期目标写清楚生成质量会高一大截。效率桌面上我离不开 Everything文件秒搜和 uTools插件化启动器前者针对 Windows后者跨平台且能装一堆小插件。RPA 自动化可以考虑影刀它在流程自动化和代码迁移场景里有不少成熟的组件可直接复用。编程之外的专项工具也有对应的速查项Python 中文分词直接选 jieba这是中文本地化处理绕不开的底子数据库运维里 SQL Server 图形化操作优先官方 SSMS代码托管体系的构建产物可以用 Nexus 或 Artifactory 做工具库部署内部依赖拉取会顺畅很多。4. 工具与框架选型的几个硬指标和避坑记录速查给的是答案但真正重要的其实是判断方法。我把自己踩过坑之后沉淀下来的选型逻辑浓缩成五个问题任何人拿到任何框架或者工具都值得先问一遍。第一问它解决的是不是我现在的真实痛点很多框架被吹得很凶但你的场景里根本不存在对应的问题。比如只有单个服务没有微服务需求就别强行上全套微服务治理框架那是在给自己造复杂度。第二问团队有几个人能维护它工具和框架的上手成本要摊到团队头上。一个人用得溜不算数要团队大部分人三天内能开始写业务才算合适。第三问社区活跃度和问题响应如何判断方法很简单——在 GitHub 上看最近三个月的 issue、提交记录和 release 频率再搜一下你想要的功能看是已经有人做了还是有一堆人在等。第四问许可证和商用约束是什么搞清 GPL、MIT、Apache 2.0 和商业授权的区别。对于出口项目尤其重要有些免费其实带着传染性条款。第五问出问题时能搜到多少真实案例冷门框架可能很好用但遇到坑时全社区只有你一个人踩那种孤立无援的感觉非常痛苦。避坑方面我整理了一个自己的红线清单量产、刷机、微码类工具只走官方渠道来源不明的修改版一律不碰商业软件的破解版不要引入工作环境合规风险和组织风险都不值得同类型工具不要装太多随身带三四个优质的胜过收藏一百个吃灰的。另外工具清单要和团队共享让新人第一天就知道我们这里装了什么、标准用法是什么而不是各自为政。5. 常见问题与排查技巧速查速查类章节必须有实操问答的落点。下面这几条是我在帮同事排查问题时遇到次数最多的整理成表方便直接对号入座。现象可能原因排查建议SSH 连不上服务器密钥权限过大、端口不对、服务没启动加-vvv看过程检查~/.ssh权限目录 700、公钥 644、私钥 600GDB 看不到源码和行号编译时没加调试信息重新编译务必加-g -O0Redis 连接被拒绝默认只绑定了 127.0.0.1、保护模式开启根据环境调整 bind 地址并设置强密码内网也要重视Rufus 做启动盘失败分区类型和镜像引导模式不匹配换 UEFI/GPT 或 Legacy/MBR 组合再试AAB 包无法直接安装设备不认 .aab 格式用 bundletool 转出 apks 再安装交叉编译的程序运行时提示 GLIBC 版本问题工具链版本落后于系统工具链版本尽量对齐目标系统或用容器统一编译环境adb 找不到设备驱动没装或调试模式未开启检查设备管理器驱动确认 USB 调试已打开换根数据线排除供电/数据线问题排查问题有个通用的顺序先看日志再看配置最后才怀疑工具本身。绝大多数所谓工具坏了的案子最后都定位到配置写错、权限不对或者版本不匹配。学会按这个顺序走能把排查效率提升好几倍。写在最后的一点经验这份附录整理到最后我想说一句真实体会框架速查和工具清单不是一次性写好的它是跟着项目演进的活文档。我每做一个新项目就会回头更新一次这份清单把真正高频使用的东西往前挪把一年都没碰过的东西丢进备选区每踩一次坑就把教训补进常见问题表里。时间长了它已经不是一张清单而是一份记录团队踩坑史和选型决策史的资料。你也可以从今天开始维护自己的版本格式不重要持续更新才重要。