你们上班不好好研究怎么写代码，就那么在乎这点京豆？ 随他爱咋咋地，自己少买点不需要的东西才是重点。

这些都是你想象出来的

“好奇经验丰富的 v 友们，报价原则是什么？如何量化？”

正经回答，这个主要看自己的收入，一个月收入经常在 3-5 万的人，不会去接你几千的外包项目，一个几个月都没收入，找工作也只能找 5-6k 工资的人，一两千的项目他也会接。

因此，关键在于你有多少钱的预算，你想把项目做成什么样子，然后再去找到正确的人。

对于没有经验的甲方，建议一开始不要开出太高的预算，先保守估计一点，低一点，多吃几次亏，然后再提高预算重新做。

如果你问“做一个美团这样的 APP 多少钱”，那么 1000 元至 10 个亿这个区间都是合理的，就看你预算了。

我接外包一般先问对方预算是否高于 10 万，低于 10 万的直接拒绝，不浪费时间聊天。

就是要先有预算，节约大家的时间。你预算多少钱都可以做。

游荡 V 站 13 年了，我居然也不知道不可以修改~

@avenger 可以的，云函数可以使用 nodejs 的库发起 http 或其他请求。

别问，一问就是蓝色的

@kuse2001 云服务器是贵许多，但是省事啊

没啥 AI 费用，这个小程序不涉及 AI 。

文本和 PC 交互是什么意思？

注册一家有限公司，假设只有自己一个人，只给自己发工资。

如果甲方打款给你，首先你可以给对方开票，资金进入公司账户，不是你的个人账户。

如果公司账面上盈利，当前税收优惠政策下基本只需要 5%的所得税+1%的增值税，一共是 6%。 但是在没有税收优惠政策下会涨到 20%所得税+3%增值税，共 23%。涉及广告、文化事业的需缴纳 3%文化事业建设费等。

假设优惠政策短期内都有，缴纳完 6%的税后，这个钱在公司账户上，如果你每个月给自己发 5000 的工资，就没有其他税费了，直到你把甲方打给你的钱都发到你自己的个人账户上。

但是，如果甲方给你的钱较多，你希望一个月发 2 、3 万，那么个人所得税就要缴纳了。

另外，不同地方对是否缴纳了五险一金的管理程度不一样，有些地方不缴纳会被罚款。

另外，开公司可能会有其他成本，例如残疾人保障金、税控盘年费、财务成本等。

@Shikinatsume

OP 已经在 85 楼明确表示此文章的重点不是服务器维护费用，此楼已经明显歪了。 为了让大家理解 OP 的重点，此贴需要让 AI 整理出文章重点，我在帮 OP 把楼掰正~

@Shikinatsume

“请尽量让自己的回复能够对别人有帮助”

我就是让回复对他人有用，这是楼上的用户的需求

@kaesi0 "不知道 up 有没有遇到比较复杂的业务逻辑，使用云函数不太方便实现的情况。"

一般来说开发者的需求就是对数据、文件（图片或其他文件）的处理，这已经包含了绝大多数 APP 和小程序的开发需求，因此不觉得会有太多的限制。 云环境也有 crontab 功能。

小程序确实在往 uniapp 方向发展，但因为我没有做 APP 的打算，所以没有关注。

@kaesi0 云函数的运行环境就是 nodejs ，应该是除了 JavaScript 和 TypeScript 外不支持其他语言的。

文章的重点分析如下：

项目挑战:

RSSHub 项目面临崩溃: 项目虽然在表面上看起来健康，拥有近 30k 星标、超过 900 名贡献者、每月超过 3 亿次请求，但实际上背后面临高昂的维护成本和过时的技术，每月服务器成本超过一千美元，加上繁琐的维护工作，使得项目濒临崩溃。

技术栈更新:

koa -> Hono: 从 koa 框架迁移到支持 JSX, TypeScript, Serverless 的 Hono 框架。
JavaScript -> TypeScript: 提高代码质量和减少类型相关错误。
CommonJS -> ESM: 采用 ESM 规范以提高兼容性和未来性。
art-template -> JSX: 使用 JSX 代替 art-template 模板引擎来提高效率和维护性。
Jest -> Vitest: 从 Jest 测试框架迁移到对 ESM 支持更好的 Vitest 。
Got -> ?: Got 库不再维护，作者正在寻找替代方案。

新路由标准:

路由信息集中: 通过新的路由标准将路由信息集中在 namespace.ts 和路由文件中，以减少错误和提高维护效率。
实施:

开发环境: 遍历路由文件夹来读取信息和加载路由。
生产环境: 使用预编译的路径列表来避免不必要的遍历和加载过程。
文档生成: 自动化生成，不再需要手动维护。


未来规划:

提出了一些新功能的想法，如 JSON 输出增强、用户系统和配置、路由错误通知和健康检查、与 RSS3 节点和加密货币收入的整合等。

文章的核心是描述了一个受欢迎的开源项目在经过六年的发展之后，如何因技术过时和维护负担重而面临崩溃，并在作者的努力下，通过采用现代技术框架和架构进行重构，使得项目得以重生。