我做过几次选型，也见过很多「选型选得很漂亮，但三个月后没人维护」的项目。独立开发者的选型标准，和大公司完全不是一回事。
先明确一个前提：你没有团队
这一条决定了所有其他标准。在公司里，选型的底线是「团队里有人会用、出问题能找到人帮忙」；但一个人维护时，出问题只能自己扛。
所以我的第一原则是：不是选最强的，而是选你出问题时能自己救回来的。
维度一：熟悉度 —— 这是合法且重要的条件
我经常看到有人在选型时刻意排除「自己已经会的」，理由是「想学新的」。在真实的独立项目里，这个理由要非常谨慎。
熟悉的技术意味着你能把精力放在「解决问题」而不是「排查框架」上；
不熟的技术会延长交付时间，而独立项目最需要的是「做完」；
想学新东西，可以用一个「失败了也无所谓」的小项目来学，不要拿主线项目练手。
维度二：长期性 —— 它三年后还在吗
独立项目通常寿命很长（因为它只有你一个人，没人会因为「立项结束」就撤走）。所以「这个技术会不会消失」是个真问题。
我判断的方式很土，但挺管用：
它背后的东西是不是一个稳定的生态（而不是某个人的实验项目）；
它的变化是不是「向下兼容」的 —— 每次升级都要求你重写，就是危险信号；
遇到问题时，能不能搜到答案（这比文档写得多漂亮更重要）。
维度三：可维护性 —— 出错时你救得回来吗
这一条最能区分「能跑」和「能长期跑」：
数据能不能自己导出、备份、迁移（不能的话就是被绑架了）；
出问题能不能看日志定位（闭源的托管服务在这点上很吃亏）；
有没有「明确的一条回滚路径」。
第一原则：少依赖
独立开发者最大的隐性成本，是「依赖升级」。每多一个依赖，就多一个会坏的零件。所以我给自己定了几个很实际的规矩：
能用标准能力做出来的，就不引第三方；
能用最简单方式解决的（比如一段自己的小工具函数），就不引一个包；
引了的东西，要写清楚「为什么需要它」，而不是「顺手就装了」。
这不是排斥工具，而是把「每一个依赖都当成一笔长期负债」来记账。
我这次的真实选型过程
这个站选型时，我把候选摊在桌上，按上面三个维度筛了一遍：
后端：选了我最熟的 Python 系框架 —— 熟悉度优先，同时它足够轻；
数据库：选了最成熟的关系型数据库 —— 长期性最好、运维资料最多；
前端：直接不引框架 —— 因为「少依赖」在这里收益最大，而且站点不需要复杂交互；
部署：用了成熟的面板与发布脚本 —— 把运维变成「照着做」，而不是「边学边配」。
这套组合有一个共同点：每一样都是「出问题时我能自己救」的。它不是最时髦的，但我敢长期维护它。
什么时候该换技术
我给自己定了几条「触发换」的条件，避免「凭感觉折腾」：
现在的方案已经无法解决核心问题（不是「不如别人优雅」）；
维护成本持续高于收益，且已经持续了相当一段时间；
有明确、可验证的收益（性能、成本、稳定性），而不是「听说更好」。
什么时候不该换 —— 这一条更重要
经验上看，「不该换」的时候远比「该换」的时候多：
只是因为它不够新；
只是因为你在别处看到别人用得更顺手；
只是因为你最近有点腻了。
独立开发里，最大的浪费不是选错技术，而是反复重选技术。把时间放在内容和交付上，收益总是更高。
一句话总结
独立开发者的选型，本质是在解一道「一个人能维护多久」的题。答案通常不是「最先进」，而是「最可控」。