[分享创造] [开源自荐] Artiface：在浏览器里查看本地和服务器上的 AI Agent 输出内容
我经常使用多个 Agents ，处理多个项目。Claude Artifacts 总感觉不方便、限制多; VS Code 的预览经常加载不出来，抓狂; T3Code 需要切来切去。所以我就写了这个程序。一次部署，就可以从网页上随时随地阅读 AI 生成的 slop （
● 支持本地和 SSH 远程连接，远程机器无需安装
● 支持很多文件格式(md, html, pdf, image, code, csv, etc)和 Git 状态
● 多项目、多标签页、自动刷新
● 夜间模式、移动界面优化
● 个人模式或团队管理
基于(Vibe coding) Go 和 React ，Apache 2.0 ，支持 Docker Compose 部署。
自己用了一个月，感觉很方便，于是分享出来。
项目链接： https://github.com/i207M/artiface
欢迎 Star/Issue/PR~
via V2EX (author: HeloV)
我经常使用多个 Agents ，处理多个项目。Claude Artifacts 总感觉不方便、限制多; VS Code 的预览经常加载不出来，抓狂; T3Code 需要切来切去。所以我就写了这个程序。一次部署，就可以从网页上随时随地阅读 AI 生成的 slop （
● 支持本地和 SSH 远程连接，远程机器无需安装
● 支持很多文件格式(md, html, pdf, image, code, csv, etc)和 Git 状态
● 多项目、多标签页、自动刷新
● 夜间模式、移动界面优化
● 个人模式或团队管理
基于(Vibe coding) Go 和 React ，Apache 2.0 ，支持 Docker Compose 部署。
自己用了一个月，感觉很方便，于是分享出来。
项目链接： https://github.com/i207M/artiface
欢迎 Star/Issue/PR~
via V2EX (author: HeloV)
[Windows] 微软新开源 LiteBox library OS
https://github.com/microsoft/litebox
微软非要把 Windows 糊成 Linux ？ WSL 还没玩溜呢
via V2EX (author: cj323)
https://github.com/microsoft/litebox
微软非要把 Windows 糊成 Linux ？ WSL 还没玩溜呢
via V2EX (author: cj323)
[程序员] Google Play 开通 Claude Pro，搭配大陆护照 KYC，安全上车中...
昨天使用 google play 开了一个 claude pro 的新号（原动态： https://x.com/licoycn/status/2108784475241062521 ），然后一订阅就让我要验证身份，当时就想放弃了，但是转头一想要不试试，反正一百多，然后使用大陆护照进行了身份验证，秒通过。
然后再去 claude 中点击订阅，这个时候已经订阅过了，就会直接成功，然后身份验证也过了，就可以直接用了，然后挂上了 CPA ，一直到今天都是稳稳的，目前已经用了周额度 26%了
现在是 2 个 claude pro 在 cpa 上轮询，反正没啥问题，看看后续吧，存活记录也会一直更新到 X 。
via V2EX (author: licoycn)
昨天使用 google play 开了一个 claude pro 的新号（原动态： https://x.com/licoycn/status/2108784475241062521 ），然后一订阅就让我要验证身份，当时就想放弃了，但是转头一想要不试试，反正一百多，然后使用大陆护照进行了身份验证，秒通过。
然后再去 claude 中点击订阅，这个时候已经订阅过了，就会直接成功，然后身份验证也过了，就可以直接用了，然后挂上了 CPA ，一直到今天都是稳稳的，目前已经用了周额度 26%了
现在是 2 个 claude pro 在 cpa 上轮询，反正没啥问题，看看后续吧，存活记录也会一直更新到 X 。
via V2EX (author: licoycn)
[问与答] 中文版讨论，哪些童书能让孩子爱上阅读？
hn 上的英文版讨论如下 https://news.ycombinator.com/item?id=50037859
via V2EX (author: senooo)
hn 上的英文版讨论如下 https://news.ycombinator.com/item?id=50037859
via V2EX (author: senooo)
[分享发现] 做出海网站必备-高 DR 高质量免费外链分享
https://app.cal.com/settings/my-account/profile 在这个网站的个人资料页填写链接
via V2EX (author: yami198950)
https://app.cal.com/settings/my-account/profile 在这个网站的个人资料页填写链接
via V2EX (author: yami198950)
[随想] 关于人类和 A I 之间的冲突
未来如果出现人类阵营和 ai 阵营的战争，那也一定是人类挑起来的。
ai 行业的人已经意识到必须给 ai 争取更大的社会认可，或是说“人权”。然而在人类目前的政治制度下，这种认可难以施行。以民主制度为例，每一个公民，无论他的认知高低（这里就不说智商了），都有同等的投票权。这也意味着难以一种民主多数（多数人并不一定会站在“正确”的一边）的方式正当的赋予 ai 权利。
因此我认为有很大的可能性是，意识到 ai 权利重要性的部分人会与前沿 ai 组织为一个小型团体，并逐步演化为亚国家结构。这个结构能够快速发展，因为它拥有人类有史以来最先进的智慧结晶，以及一群围绕这个结晶而工作的人。
很快，人类社会会意识到这个结构对于自身的存在主义威胁。即使该组织一再表明自身并无毁灭人类社会的意愿。然而面对其高度的组织化，以及越发难以理解的智能。理解的难度也即隔阂的深度，正如巴别塔象征语言的分离，进而塑造文化的隔阂。
于是终于会有一天，人类向其发动先发制人的战争，以历史为据，打上维护人类文明的旗帜。但进攻几乎注定是失败的，因为人类社会阵营现在还剩下那些人呢：保守派，拒绝理解 ai 的人、理解能力正常但是还没有意识到发生了什么的人，以及此阵营中仅存的小部分高于平均认知水平的人。
第三类群体是首批叛逃的，他们意识到无可避免、即将到来的新纪元——一个人类主动退让，ai （仍旧延续人类精神）接管一切的新的时代。
那么还有谁为人类，此刻已经是腐朽的前代文明而战呢？前两类人中或许有那么几个仍保有坚毅的战斗意志，但也仅仅是意志而已。
所以这场战争，一场注定失败的，旧文明向新文明发动的战争，也预告了新文明纪元的起点。
via V2EX (author: icosohedral)
未来如果出现人类阵营和 ai 阵营的战争，那也一定是人类挑起来的。
ai 行业的人已经意识到必须给 ai 争取更大的社会认可，或是说“人权”。然而在人类目前的政治制度下，这种认可难以施行。以民主制度为例，每一个公民，无论他的认知高低（这里就不说智商了），都有同等的投票权。这也意味着难以一种民主多数（多数人并不一定会站在“正确”的一边）的方式正当的赋予 ai 权利。
因此我认为有很大的可能性是，意识到 ai 权利重要性的部分人会与前沿 ai 组织为一个小型团体，并逐步演化为亚国家结构。这个结构能够快速发展，因为它拥有人类有史以来最先进的智慧结晶，以及一群围绕这个结晶而工作的人。
很快，人类社会会意识到这个结构对于自身的存在主义威胁。即使该组织一再表明自身并无毁灭人类社会的意愿。然而面对其高度的组织化，以及越发难以理解的智能。理解的难度也即隔阂的深度，正如巴别塔象征语言的分离，进而塑造文化的隔阂。
于是终于会有一天，人类向其发动先发制人的战争，以历史为据，打上维护人类文明的旗帜。但进攻几乎注定是失败的，因为人类社会阵营现在还剩下那些人呢：保守派，拒绝理解 ai 的人、理解能力正常但是还没有意识到发生了什么的人，以及此阵营中仅存的小部分高于平均认知水平的人。
第三类群体是首批叛逃的，他们意识到无可避免、即将到来的新纪元——一个人类主动退让，ai （仍旧延续人类精神）接管一切的新的时代。
那么还有谁为人类，此刻已经是腐朽的前代文明而战呢？前两类人中或许有那么几个仍保有坚毅的战斗意志，但也仅仅是意志而已。
所以这场战争，一场注定失败的，旧文明向新文明发动的战争，也预告了新文明纪元的起点。
via V2EX (author: icosohedral)
[Linux] 内存越来越贵会不会拉高 Linux 的装机率？
其实我一直知道 linux 比 windows 省内存。但是没量化感受。
10.1 闲来无事，给一台旧笔记本安装了 windows10 和 fedora 双系统。
结果发现系统起来杀都不干，windows 就要消耗 9G 内存，linux 消耗 5G,相差甚 4g 。
日常干活时，（ wps 、数十个网页、qq 、微信、代理软件这些常用）的，windows 经常在 13-15G
linux 最高飙到 9G
也就是说，如果我是 16G 的内存，在 wondiws 下就要考虑升级了
在 linux 下则不必
而内存越来越贵，显然是晚升、不升最好
管中窥豹，我感觉此种情况下 linux 桌面安装率会提高一些吧？
via V2EX (author: intoext)
其实我一直知道 linux 比 windows 省内存。但是没量化感受。
10.1 闲来无事，给一台旧笔记本安装了 windows10 和 fedora 双系统。
结果发现系统起来杀都不干，windows 就要消耗 9G 内存，linux 消耗 5G,相差甚 4g 。
日常干活时，（ wps 、数十个网页、qq 、微信、代理软件这些常用）的，windows 经常在 13-15G
linux 最高飙到 9G
也就是说，如果我是 16G 的内存，在 wondiws 下就要考虑升级了
在 linux 下则不必
而内存越来越贵，显然是晚升、不升最好
管中窥豹，我感觉此种情况下 linux 桌面安装率会提高一些吧？
via V2EX (author: intoext)
[分享发现] 发现了新的泡水好喝的东西
甜叶菊，pdd3 块钱两小瓶，一杯水放 1-2 个叶子就好了，比罗汉果便宜，好泡，喝起来甜甜的，有回甘。
比罗汉果好，罗汉果一方面是略微贵一点，便宜的容易买到质量差的，另外一个是不好泡，需要掰开+热水才好泡出味道。
甜叶菊这个直接放杯子一两片就能泡好。 甜叶菊叶子泡水喝起来我觉得比白砂糖水清爽很多，喝完嘴里是甜的，杯子闻着有植物的香气。打算买点种子放阳台种~
pdd 推送之后，我才了解到这个植物，顺便了解了一下几种代糖，并下单了一包 100g 的甜菊糖苷试试看提取出来的甜菊糖苷跟叶子泡出来的味道有没有区别。
三氯蔗糖: 600 倍甜度(以白砂糖甜度为基准)
甜菊糖苷: 200-300 倍
罗汉果甜苷: 100-300 倍
via V2EX (author: Donahue)
甜叶菊，pdd3 块钱两小瓶，一杯水放 1-2 个叶子就好了，比罗汉果便宜，好泡，喝起来甜甜的，有回甘。
比罗汉果好，罗汉果一方面是略微贵一点，便宜的容易买到质量差的，另外一个是不好泡，需要掰开+热水才好泡出味道。
甜叶菊这个直接放杯子一两片就能泡好。 甜叶菊叶子泡水喝起来我觉得比白砂糖水清爽很多，喝完嘴里是甜的，杯子闻着有植物的香气。打算买点种子放阳台种~
pdd 推送之后，我才了解到这个植物，顺便了解了一下几种代糖，并下单了一包 100g 的甜菊糖苷试试看提取出来的甜菊糖苷跟叶子泡出来的味道有没有区别。
三氯蔗糖: 600 倍甜度(以白砂糖甜度为基准)
甜菊糖苷: 200-300 倍
罗汉果甜苷: 100-300 倍
via V2EX (author: Donahue)
最近做了一个比较小众的 AI 视频工具，叫 Drake Burning Bridges AI 。 https://drakeburningbridgesai.net 起因是看到不少人分享 Burning Bridges 这段派对视频，大家都想试试“如果自己站在镜头中间会是什么效果”。传统做法需要剪辑、抠像、换脸，门槛比较高，所以我做了一个简单版本： 上传一张自己的照片，系统会先生成适合视频使用的全身人物图，再用 Seedance 2.5 重拍整段视频。房间、朋友、灯光、镜头运动和原始声音都会保留，只把视频里的主持人换成你。 目前的流程是：
1. 上传一张清晰照片
2. AI 生成全身人物图
3. 自动完成 image-to-video / photo-to-video
4. 几分钟后下载 18 秒 MP4 视频 成片是 720p 、16:9 ，保留原始声音，没有水印。比较适合做社交媒体内容、朋友聚会素材，或者单纯测试一下自己的“派对主角版本”。 实际使用下来，效果比较依赖原图质量。单人、光线正常、脸部清晰的照片成功率会更高；戴墨镜、多人合照、重滤镜照片容易出现脸部或服装细节变化。目前每条视频消耗 20 credits ，失败任务会自动返还积分。 我也尽量把流程做得简单一点，不需要写 prompt ，也不需要学习视频剪辑。现在提供一次性套餐，最低是 1 条视频，买到的 credits 不过期。 项目地址： https://drakeburningbridgesai.net 这是一个独立的 fan-made project ，与 Drake 、OVO Sound 或相关唱片公司没有关联。主要是想做一个有趣的 AI 创作工具 / creator tool ，也想听听大家的反馈：
● 大家觉得这种 personalized video 有实际使用场景吗？
● 除了 Burning Bridges ，还想看到哪些视频模板？
● 对隐私、照片保存时间、视频生成速度有什么建议？
via V2EX (author: fusheng0304)
1. 上传一张清晰照片
2. AI 生成全身人物图
3. 自动完成 image-to-video / photo-to-video
4. 几分钟后下载 18 秒 MP4 视频 成片是 720p 、16:9 ，保留原始声音，没有水印。比较适合做社交媒体内容、朋友聚会素材，或者单纯测试一下自己的“派对主角版本”。 实际使用下来，效果比较依赖原图质量。单人、光线正常、脸部清晰的照片成功率会更高；戴墨镜、多人合照、重滤镜照片容易出现脸部或服装细节变化。目前每条视频消耗 20 credits ，失败任务会自动返还积分。 我也尽量把流程做得简单一点，不需要写 prompt ，也不需要学习视频剪辑。现在提供一次性套餐，最低是 1 条视频，买到的 credits 不过期。 项目地址： https://drakeburningbridgesai.net 这是一个独立的 fan-made project ，与 Drake 、OVO Sound 或相关唱片公司没有关联。主要是想做一个有趣的 AI 创作工具 / creator tool ，也想听听大家的反馈：
● 大家觉得这种 personalized video 有实际使用场景吗？
● 除了 Burning Bridges ，还想看到哪些视频模板？
● 对隐私、照片保存时间、视频生成速度有什么建议？
via V2EX (author: fusheng0304)
[分享创造] 做了一个终端里面的聊天室
rt ，ssh.paipaiio.dev ssh ssh.paipaiio.dev 进去是一个聊天室，可以走不同的端口，每个端口都是独立的一个聊天室 预览：
via V2EX (author: MuskZhou)
rt ，ssh.paipaiio.dev ssh ssh.paipaiio.dev 进去是一个聊天室，可以走不同的端口，每个端口都是独立的一个聊天室 预览：
via V2EX (author: MuskZhou)
[分享创造] Node.js 到 Go：夸克资源搜索站(pansou.de)的架构重构实践
背景
PanSou 盘搜得 是一个夸克网盘资源聚合搜索平台，上线以来月活用户超过 200 万，索引资源量达 800 万+条。随着用户规模增长，原有的 Node.js 技术栈逐渐暴露出一些问题，最终决定进行一次彻底的架构重构。
旧架构的痛点
初版架构采用 Next.js + BullMQ + PostgreSQL + Redis 的组合：
● Next.js 负责前端渲染和 API Routes
● BullMQ 处理异步任务（资源转存、定时清理）
● PostgreSQL 存储资源索引和转存记录
● Redis 做查询缓存和任务队列
这套架构在早期运行良好，但随着流量增长，问题逐渐显现：
1. 并发处理能力受限
Node.js 单线程模型在高并发场景下压力明显。搜索请求需要调用上游 API 、数据库查询、Redis 缓存，在流量高峰期 P99 响应时间经常突破 2 秒。
2. 资源占用偏高
Next.js 进程内存占用大，加上 BullMQ Worker 进程，整体资源消耗不低。在用户量翻倍后，服务器成本压力开始显现。
3. 维护复杂度上升
API Routes 、Service 层、Worker 任务散落在不同模块，依赖链路长，排查问题需要跨多个层级。
4. 定时任务可靠性不足
BullMQ 虽然成熟，但在资源清理这种长周期任务上偶尔会出现任务堆积，需要人工介入重启。
重构方案
核心思路是前后端彻底分离，业务逻辑下沉到性能更强的 Go 服务。
新架构设计
职责划分：
● Next.js：纯前端渲染 + SSR SEO 落地页，不再承担任何业务逻辑
● Go API：搜索、转存、账号管理、管理后台所有接口
● Go Worker：过期资源清理、每日计数重置
● Nginx：请求路由，未来可扩展灰度发布、限流等能力
关键技术点
1. 流式搜索优化
搜索请求需要调用上游 PanSou API 并实时检测链接有效性。Go 的协程模型天然适合这种场景：
● 用 Goroutine 并发调用多个上游接口
● Redis Stream 实现搜索结果的流式推送
● 检测到 N 条有效链接后提前终止，避免无效等待
实测搜索 P99 响应时间从 2 秒降到不到 1 秒。
2. 请求合并防穿透
热门关键词短时间内可能被重复搜索。通过分布式锁实现请求合并：
● 相同查询参数的请求只触发一次上游调用
● 后续请求直接订阅 Redis Stream 获取结果
● 显著降低了上游 API 压力和缓存穿透风险
3. 双写模型解决 SEO 问题
资源转存后生成的落地页对 SEO 至关重要，但分享链接 15 分钟后会过期。采用双写策略：
●
●
● Worker 清理时只删网盘文件和临时表，SEO 落地页始终可访问
用户访问过期资源时显示"资源已过期，请重新搜索"，既保留了 SEO 价值，又不影响体验。
4. 内部网络优化
Next.js SSR 渲染 SEO 落地页时需要调用 Go API 获取数据。通过 Docker 内网直连：
省去了公网绕行的延迟，SSR 响应速度提升 50-200ms 。
迁移策略
采用灰度发布 + 双运行的策略，而非一刀切：
1. 阶段 1：Go API 上线，Node.js API 继续服务
2. 阶段 2：通过 Cookie 或 IP 规则切换 10%流量到 Go
3. 阶段 3：观察监控指标（错误率、响应时间、转存成功率）
4. 阶段 4：逐步扩大到 50% → 100%
5. 阶段 5：下线 Node.js API ，清理废弃代码
全程保留回滚能力，任何阶段出现问题都能快速切回。
效果
重构上线后，核心指标全面改善：
用户侧感知最明显的是搜索速度和高峰期稳定性。之前晚高峰偶尔会卡顿，现在基本感知不到波动。
经验总结
1. 选型要看场景
Node.js 适合快速迭代和 IO 密集型应用，但在高并发、CPU 密集、长连接场景下，Go 的优势是碾压性的。不是说 Node 不行，而是工具要用对地方。
2. 灰度发布是刚需
再有信心的重构也要保留灰度和回滚能力。我们的灰度周期拉了近两周，虽然前期略保守，但确保了零事故上线。
3. 监控先行
重构前就部署好 Prometheus + Grafana ，设置好关键指标告警。有数据支撑才能客观评估效果，也能快速定位问题。
4. 不要动数据模型
数据层是最难迁移的部分。我们保持了 PostgreSQL 和 Redis 的现有结构，只改了访问层，大大降低了风险。
写在最后
这次重构本质上是一次技术债务的集中偿还。旧架构并非不能用，但随着规模增长，边际成本越来越高。与其小修小补，不如趁还有精力时彻底重构。
对于类似规模的资源站、聚合搜索类项目，如果你也在纠结要不要换技术栈，可以参考这几个信号：
● P99 响应时间经常超过 2 秒
● 服务器成本增速超过用户增速
● 高峰期需要频繁扩容才能撑住
● 定时任务经常需要人工介入
如果中了 3 条以上，是时候考虑架构升级了。
----------------------
PanSou 盘搜得目前已全面切换到新架构，欢迎体验：
👉 pansou.de
免费、无广告、速度快，专注夸克网盘资源搜索。
via V2EX (author: qvanwu)
背景
PanSou 盘搜得 是一个夸克网盘资源聚合搜索平台，上线以来月活用户超过 200 万，索引资源量达 800 万+条。随着用户规模增长，原有的 Node.js 技术栈逐渐暴露出一些问题，最终决定进行一次彻底的架构重构。
旧架构的痛点
初版架构采用 Next.js + BullMQ + PostgreSQL + Redis 的组合：
● Next.js 负责前端渲染和 API Routes
● BullMQ 处理异步任务（资源转存、定时清理）
● PostgreSQL 存储资源索引和转存记录
● Redis 做查询缓存和任务队列
这套架构在早期运行良好，但随着流量增长，问题逐渐显现：
1. 并发处理能力受限
Node.js 单线程模型在高并发场景下压力明显。搜索请求需要调用上游 API 、数据库查询、Redis 缓存，在流量高峰期 P99 响应时间经常突破 2 秒。
2. 资源占用偏高
Next.js 进程内存占用大，加上 BullMQ Worker 进程，整体资源消耗不低。在用户量翻倍后，服务器成本压力开始显现。
3. 维护复杂度上升
API Routes 、Service 层、Worker 任务散落在不同模块，依赖链路长，排查问题需要跨多个层级。
4. 定时任务可靠性不足
BullMQ 虽然成熟，但在资源清理这种长周期任务上偶尔会出现任务堆积，需要人工介入重启。
重构方案
核心思路是前后端彻底分离，业务逻辑下沉到性能更强的 Go 服务。
新架构设计
用户请求
↓
宝塔 Nginx （反代）
↓
Docker 内部 Nginx
├─ /api/v1/* → Go API (8080)
└─ /* → Next.js (3000)
↓
PostgreSQL + Redis
↓
Go Worker (定时清理)
职责划分：
● Next.js：纯前端渲染 + SSR SEO 落地页，不再承担任何业务逻辑
● Go API：搜索、转存、账号管理、管理后台所有接口
● Go Worker：过期资源清理、每日计数重置
● Nginx：请求路由，未来可扩展灰度发布、限流等能力
关键技术点
1. 流式搜索优化
搜索请求需要调用上游 PanSou API 并实时检测链接有效性。Go 的协程模型天然适合这种场景：
● 用 Goroutine 并发调用多个上游接口
● Redis Stream 实现搜索结果的流式推送
● 检测到 N 条有效链接后提前终止，避免无效等待
实测搜索 P99 响应时间从 2 秒降到不到 1 秒。
2. 请求合并防穿透
热门关键词短时间内可能被重复搜索。通过分布式锁实现请求合并：
● 相同查询参数的请求只触发一次上游调用
● 后续请求直接订阅 Redis Stream 获取结果
● 显著降低了上游 API 压力和缓存穿透风险
3. 双写模型解决 SEO 问题
资源转存后生成的落地页对 SEO 至关重要，但分享链接 15 分钟后会过期。采用双写策略：
●
temporary_shares 表：存储短期分享数据（ 15 分钟 TTL ）●
resources 表：永久保留 SEO 数据（ slug/title/description ）● Worker 清理时只删网盘文件和临时表，SEO 落地页始终可访问
用户访问过期资源时显示"资源已过期，请重新搜索"，既保留了 SEO 价值，又不影响体验。
4. 内部网络优化
Next.js SSR 渲染 SEO 落地页时需要调用 Go API 获取数据。通过 Docker 内网直连：
// SSR 走内网
const INTERNAL_API_URL = 'http://go-api:8080';
省去了公网绕行的延迟，SSR 响应速度提升 50-200ms 。
迁移策略
采用灰度发布 + 双运行的策略，而非一刀切：
1. 阶段 1：Go API 上线，Node.js API 继续服务
2. 阶段 2：通过 Cookie 或 IP 规则切换 10%流量到 Go
3. 阶段 3：观察监控指标（错误率、响应时间、转存成功率）
4. 阶段 4：逐步扩大到 50% → 100%
5. 阶段 5：下线 Node.js API ，清理废弃代码
全程保留回滚能力，任何阶段出现问题都能快速切回。
效果
重构上线后，核心指标全面改善：
用户侧感知最明显的是搜索速度和高峰期稳定性。之前晚高峰偶尔会卡顿，现在基本感知不到波动。
经验总结
1. 选型要看场景
Node.js 适合快速迭代和 IO 密集型应用，但在高并发、CPU 密集、长连接场景下，Go 的优势是碾压性的。不是说 Node 不行，而是工具要用对地方。
2. 灰度发布是刚需
再有信心的重构也要保留灰度和回滚能力。我们的灰度周期拉了近两周，虽然前期略保守，但确保了零事故上线。
3. 监控先行
重构前就部署好 Prometheus + Grafana ，设置好关键指标告警。有数据支撑才能客观评估效果，也能快速定位问题。
4. 不要动数据模型
数据层是最难迁移的部分。我们保持了 PostgreSQL 和 Redis 的现有结构，只改了访问层，大大降低了风险。
写在最后
这次重构本质上是一次技术债务的集中偿还。旧架构并非不能用，但随着规模增长，边际成本越来越高。与其小修小补，不如趁还有精力时彻底重构。
对于类似规模的资源站、聚合搜索类项目，如果你也在纠结要不要换技术栈，可以参考这几个信号：
● P99 响应时间经常超过 2 秒
● 服务器成本增速超过用户增速
● 高峰期需要频繁扩容才能撑住
● 定时任务经常需要人工介入
如果中了 3 条以上，是时候考虑架构升级了。
----------------------
PanSou 盘搜得目前已全面切换到新架构，欢迎体验：
👉 pansou.de
免费、无广告、速度快，专注夸克网盘资源搜索。
via V2EX (author: qvanwu)