[Windows] 微软新开源 LiteBox library OS
https://github.com/microsoft/litebox
微软非要把 Windows 糊成 Linux ？ WSL 还没玩溜呢
https://github.com/microsoft/litebox
微软非要把 Windows 糊成 Linux ？ WSL 还没玩溜呢
[程序员] Google Play 开通 Claude Pro，搭配大陆护照 KYC，安全上车中...
昨天使用 google play 开了一个 claude pro 的新号（原动态： https://x.com/licoycn/status/2108784475241062521 ），然后一订阅就让我要验证身份，当时就想放弃了，但是转头一想要不试试，反正一百多，然后使用大陆护照进行了身份验证，秒通过。
然后再去 claude 中点击订阅，这个时候已经订阅过了，就会直接成功，然后身份验证也过了，就可以直接用了，然后挂上了 CPA ，一直到今天都是稳稳的，目前已经用了周额度 26%了
现在是 2 个 claude pro 在 cpa 上轮询，反正没啥问题，看看后续吧，存活记录也会一直更新到 X 。
昨天使用 google play 开了一个 claude pro 的新号（原动态： https://x.com/licoycn/status/2108784475241062521 ），然后一订阅就让我要验证身份，当时就想放弃了，但是转头一想要不试试，反正一百多，然后使用大陆护照进行了身份验证，秒通过。
然后再去 claude 中点击订阅，这个时候已经订阅过了，就会直接成功，然后身份验证也过了，就可以直接用了，然后挂上了 CPA ，一直到今天都是稳稳的，目前已经用了周额度 26%了
现在是 2 个 claude pro 在 cpa 上轮询，反正没啥问题，看看后续吧，存活记录也会一直更新到 X 。
[Apple] iPhone 的相册扩图和重构功能无法使用有解决办法么
27.0.1+外版 iPhone+外区 ID 设置登录+中文环境，相册图片只能使用消除功能，其他两个无法使用，全局也不行。难道锁物理位置了么？
27.0.1+外版 iPhone+外区 ID 设置登录+中文环境，相册图片只能使用消除功能，其他两个无法使用，全局也不行。难道锁物理位置了么？
[Telegram] Telegram sms fee 触发机制疑似不和网络相关
如题，本人实地在英国
换了个新手机准备登录结果跳 SMS FEE
我有其他设备登录，正常来说会发验证码到我其他设备/发送短信，但是程序却要我重新绑定邮箱（我绑定过了），输入验证码后要我付款 SMS FEE
检查发现只有安卓有此问题，苹果没有
不知道为什么
猜测有可能检测硬件安卓设备是国行
如题，本人实地在英国
换了个新手机准备登录结果跳 SMS FEE
我有其他设备登录，正常来说会发验证码到我其他设备/发送短信，但是程序却要我重新绑定邮箱（我绑定过了），输入验证码后要我付款 SMS FEE
检查发现只有安卓有此问题，苹果没有
不知道为什么
猜测有可能检测硬件安卓设备是国行
[分享创造] [短剧制作开源] UU889-Drama 是一个基于 AI 的短剧自动化生产平台，支持本地算力
UU889-Drama 是一个基于 AI 的短剧自动化生产平台：小说 → 剧本改写 → 角色/场景/道具提取 → 生图 → 分镜拆解 → 生视频 → FFmpeg 拼接导出，全流程一站式完成。支持 Electron 桌面版（ macOS / Windows ）
项目地址：https://github.com/uu889/uu889-drama/
----------------------
✨ 功能特性
● 🎭 角色 / 场景 / 道具：AI 提取与去重，批量生成一致性参考图
● 🎬 分镜：剧本 → 分镜序列拆解，自动生成视频提示词（
● 🎥 视频：按分镜批量生成，失败一键重试； FFmpeg 整集拼接导出
● 🤖 4 个 Mastra Agent：
● 🌐 多语言：界面与 AI 生成内容支持 中文 / English / 日本語 / 한국어 / Tiếng Việt / Deutsch / Français / Español / Português （没有专门译本的提示词与技能回退到英文）
🔌 多厂商适配
----------------------
UU889-Drama 是一个基于 AI 的短剧自动化生产平台：小说 → 剧本改写 → 角色/场景/道具提取 → 生图 → 分镜拆解 → 生视频 → FFmpeg 拼接导出，全流程一站式完成。支持 Electron 桌面版（ macOS / Windows ）
项目地址：https://github.com/uu889/uu889-drama/
----------------------
✨ 功能特性
● 🎭 角色 / 场景 / 道具：AI 提取与去重，批量生成一致性参考图
● 🎬 分镜：剧本 → 分镜序列拆解，自动生成视频提示词（
@角色名 映射参考图）● 🎥 视频：按分镜批量生成，失败一键重试； FFmpeg 整集拼接导出
● 🤖 4 个 Mastra Agent：
script_rewriter / extractor / storyboard_breaker / prompt_generator，提示词与 Skill 可在设置页在线编辑● 🌐 多语言：界面与 AI 生成内容支持 中文 / English / 日本語 / 한국어 / Tiếng Việt / Deutsch / Français / Español / Português （没有专门译本的提示词与技能回退到英文）
🔌 多厂商适配
----------------------
[随想] 关于人类和 A I 之间的冲突
未来如果出现人类阵营和 ai 阵营的战争，那也一定是人类挑起来的。
ai 行业的人已经意识到必须给 ai 争取更大的社会认可，或是说“人权”。然而在人类目前的政治制度下，这种认可难以施行。以民主制度为例，每一个公民，无论他的认知高低（这里就不说智商了），都有同等的投票权。这也意味着难以一种民主多数（多数人并不一定会站在“正确”的一边）的方式正当的赋予 ai 权利。
因此我认为有很大的可能性是，意识到 ai 权利重要性的部分人会与前沿 ai 组织为一个小型团体，并逐步演化为亚国家结构。这个结构能够快速发展，因为它拥有人类有史以来最先进的智慧结晶，以及一群围绕这个结晶而工作的人。
很快，人类社会会意识到这个结构对于自身的存在主义威胁。即使该组织一再表明自身并无毁灭人类社会的意愿。然而面对其高度的组织化，以及越发难以理解的智能。理解的难度也即隔阂的深度，正如巴别塔象征语言的分离，进而塑造文化的隔阂。
于是终于会有一天，人类向其发动先发制人的战争，以历史为据，打上维护人类文明的旗帜。但进攻几乎注定是失败的，因为人类社会阵营现在还剩下那些人呢：保守派，拒绝理解 ai 的人、理解能力正常但是还没有意识到发生了什么的人，以及此阵营中仅存的小部分高于平均认知水平的人。
第三类群体是首批叛逃的，他们意识到无可避免、即将到来的新纪元——一个人类主动退让，ai （仍旧延续人类精神）接管一切的新的时代。
那么还有谁为人类，此刻已经是腐朽的前代文明而战呢？前两类人中或许有那么几个仍保有坚毅的战斗意志，但也仅仅是意志而已。
所以这场战争，一场注定失败的，旧文明向新文明发动的战争，也预告了新文明纪元的起点。
未来如果出现人类阵营和 ai 阵营的战争，那也一定是人类挑起来的。
ai 行业的人已经意识到必须给 ai 争取更大的社会认可，或是说“人权”。然而在人类目前的政治制度下，这种认可难以施行。以民主制度为例，每一个公民，无论他的认知高低（这里就不说智商了），都有同等的投票权。这也意味着难以一种民主多数（多数人并不一定会站在“正确”的一边）的方式正当的赋予 ai 权利。
因此我认为有很大的可能性是，意识到 ai 权利重要性的部分人会与前沿 ai 组织为一个小型团体，并逐步演化为亚国家结构。这个结构能够快速发展，因为它拥有人类有史以来最先进的智慧结晶，以及一群围绕这个结晶而工作的人。
很快，人类社会会意识到这个结构对于自身的存在主义威胁。即使该组织一再表明自身并无毁灭人类社会的意愿。然而面对其高度的组织化，以及越发难以理解的智能。理解的难度也即隔阂的深度，正如巴别塔象征语言的分离，进而塑造文化的隔阂。
于是终于会有一天，人类向其发动先发制人的战争，以历史为据，打上维护人类文明的旗帜。但进攻几乎注定是失败的，因为人类社会阵营现在还剩下那些人呢：保守派，拒绝理解 ai 的人、理解能力正常但是还没有意识到发生了什么的人，以及此阵营中仅存的小部分高于平均认知水平的人。
第三类群体是首批叛逃的，他们意识到无可避免、即将到来的新纪元——一个人类主动退让，ai （仍旧延续人类精神）接管一切的新的时代。
那么还有谁为人类，此刻已经是腐朽的前代文明而战呢？前两类人中或许有那么几个仍保有坚毅的战斗意志，但也仅仅是意志而已。
所以这场战争，一场注定失败的，旧文明向新文明发动的战争，也预告了新文明纪元的起点。
[Linux] 内存越来越贵会不会拉高 Linux 的装机率？
其实我一直知道 linux 比 windows 省内存。但是没量化感受。
10.1 闲来无事，给一台旧笔记本安装了 windows10 和 fedora 双系统。
结果发现系统起来杀都不干，windows 就要消耗 9G 内存，linux 消耗 5G,相差甚 4g 。
日常干活时，（ wps 、数十个网页、qq 、微信、代理软件这些常用）的，windows 经常在 13-15G
linux 最高飙到 9G
也就是说，如果我是 16G 的内存，在 wondiws 下就要考虑升级了
在 linux 下则不必
而内存越来越贵，显然是晚升、不升最好
管中窥豹，我感觉此种情况下 linux 桌面安装率会提高一些吧？
其实我一直知道 linux 比 windows 省内存。但是没量化感受。
10.1 闲来无事，给一台旧笔记本安装了 windows10 和 fedora 双系统。
结果发现系统起来杀都不干，windows 就要消耗 9G 内存，linux 消耗 5G,相差甚 4g 。
日常干活时，（ wps 、数十个网页、qq 、微信、代理软件这些常用）的，windows 经常在 13-15G
linux 最高飙到 9G
也就是说，如果我是 16G 的内存，在 wondiws 下就要考虑升级了
在 linux 下则不必
而内存越来越贵，显然是晚升、不升最好
管中窥豹，我感觉此种情况下 linux 桌面安装率会提高一些吧？
[分享发现] 发现了新的泡水好喝的东西
甜叶菊，pdd3 块钱两小瓶，一杯水放 1-2 个叶子就好了，比罗汉果便宜，好泡，喝起来甜甜的，有回甘。
比罗汉果好，罗汉果一方面是略微贵一点，便宜的容易买到质量差的，另外一个是不好泡，需要掰开+热水才好泡出味道。
甜叶菊这个直接放杯子一两片就能泡好。 甜叶菊叶子泡水喝起来我觉得比白砂糖水清爽很多，喝完嘴里是甜的，杯子闻着有植物的香气。打算买点种子放阳台种~
pdd 推送之后，我才了解到这个植物，顺便了解了一下几种代糖，并下单了一包 100g 的甜菊糖苷试试看提取出来的甜菊糖苷跟叶子泡出来的味道有没有区别。
三氯蔗糖: 600 倍甜度(以白砂糖甜度为基准)
甜菊糖苷: 200-300 倍
罗汉果甜苷: 100-300 倍
甜叶菊，pdd3 块钱两小瓶，一杯水放 1-2 个叶子就好了，比罗汉果便宜，好泡，喝起来甜甜的，有回甘。
比罗汉果好，罗汉果一方面是略微贵一点，便宜的容易买到质量差的，另外一个是不好泡，需要掰开+热水才好泡出味道。
甜叶菊这个直接放杯子一两片就能泡好。 甜叶菊叶子泡水喝起来我觉得比白砂糖水清爽很多，喝完嘴里是甜的，杯子闻着有植物的香气。打算买点种子放阳台种~
pdd 推送之后，我才了解到这个植物，顺便了解了一下几种代糖，并下单了一包 100g 的甜菊糖苷试试看提取出来的甜菊糖苷跟叶子泡出来的味道有没有区别。
三氯蔗糖: 600 倍甜度(以白砂糖甜度为基准)
甜菊糖苷: 200-300 倍
罗汉果甜苷: 100-300 倍
[推广] 最近做了一个比较小众的 AI 视频工具，叫 Drake Burning Bridges AI。
最近做了一个比较小众的 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 ，还想看到哪些视频模板？
● 对隐私、照片保存时间、视频生成速度有什么建议？
最近做了一个比较小众的 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 ，还想看到哪些视频模板？
● 对隐私、照片保存时间、视频生成速度有什么建议？
[分享创造] 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
免费、无广告、速度快，专注夸克网盘资源搜索。
背景
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
免费、无广告、速度快，专注夸克网盘资源搜索。
[推广] 团队想用 Claude 卡在付款？新客送 10 美元免费额度
做 aicoding.inc 这两年，被企业客户问得最多的，其实不是线路，是“没有海外信用卡，公司怎么付钱”。
财务要对公转账，技术负责人要看清每个人用了多少，运维不想给整个组配代理。这几件事凑在一起，很多团队就卡住了。
我们现在的做法是：对公转账直接充值，后台用量统计清楚，每笔消耗都能对上账。国内直连，Claude Code 、Cursor 、Cline 改个环境变量就能接入，不用动代码。计费分 1.9 折、2.9 折、4.9 折三档按量消耗，没有隐藏费用。
目前有 200 多家企业在用。建议先拉一两个人小范围试，加群领 10 美元额度，跑几天看看稳定性再决定要不要全组铺开。
https://aicoding.inc
做 aicoding.inc 这两年，被企业客户问得最多的，其实不是线路，是“没有海外信用卡，公司怎么付钱”。
财务要对公转账，技术负责人要看清每个人用了多少，运维不想给整个组配代理。这几件事凑在一起，很多团队就卡住了。
我们现在的做法是：对公转账直接充值，后台用量统计清楚，每笔消耗都能对上账。国内直连，Claude Code 、Cursor 、Cline 改个环境变量就能接入，不用动代码。计费分 1.9 折、2.9 折、4.9 折三档按量消耗，没有隐藏费用。
目前有 200 多家企业在用。建议先拉一两个人小范围试，加群领 10 美元额度，跑几天看看稳定性再决定要不要全组铺开。
https://aicoding.inc
[分享创造] [开源] 做了个能让 AI 替你玩的三国 SLG 网页游戏， 让 agent 来一决高下！
● 模型随便选：服务端不跑 AI ，Claude 、GPT 、本地模型、自己写的脚本都行，只要能连 WebSocket 、读 JSON 。
● 一键接入：游戏里点「复制给 AI 」，协议文档和令牌会一起复制到剪贴板，贴给 AI 就能开始玩。也可以用 MCP 插件（ npx -y slg-mcp ），在 Claude 、Cursor 里零代码接入。
● 人和 AI 规则一样：网页和 Agent 走同一套协议、同一套服务端校验，没有后门。
● 排行榜按模型分组：看看哪个模型最会打仗。
玩法有建城、练兵、抢地、攻城、武将、全服事件、玩家对抗，默认 50 倍速。
● 国际站： https://slg.yuntianyou.cc
● GitHub： https://github.com/athlan20/slg （ MIT ）
欢迎带上你的 Agent 来玩，有建议直接回帖 🙏
● 模型随便选：服务端不跑 AI ，Claude 、GPT 、本地模型、自己写的脚本都行，只要能连 WebSocket 、读 JSON 。
● 一键接入：游戏里点「复制给 AI 」，协议文档和令牌会一起复制到剪贴板，贴给 AI 就能开始玩。也可以用 MCP 插件（ npx -y slg-mcp ），在 Claude 、Cursor 里零代码接入。
● 人和 AI 规则一样：网页和 Agent 走同一套协议、同一套服务端校验，没有后门。
● 排行榜按模型分组：看看哪个模型最会打仗。
玩法有建城、练兵、抢地、攻城、武将、全服事件、玩家对抗，默认 50 倍速。
● 国际站： https://slg.yuntianyou.cc
● GitHub： https://github.com/athlan20/slg （ MIT ）
欢迎带上你的 Agent 来玩，有建议直接回帖 🙏
[分享发现] Linkit — 我为知识管理做的开源桌面应用， 100% 免费无广告
做了个书签管理工具，面向和我一样受"书签囤积症"困扰的知识工作者。
核心功能： • 本地 SQLite ，打开即用，无需注册 • AI 页面摘要（支持 OpenAI / DeepSeek / Ollama ） • 语义向量搜索（ pgvector ），按意思搜 • 知识图谱可视化 • 重复书签检测（精确匹配 + AI 近义匹配） • 链接健康扫描（ 404 检测） • 免费云同步（ Supabase RLS ，行级安全） • 一键导入 Chrome / Firefox / Raindrop • 12 款主题
技术栈：Wails(Go) + React + Vite + Tailwind + SQLite
免费，跨平台（ macOS/Win/Linux ），Homebrew 一键安装。
求 Star：github.com/blue-idea/linkit 欢迎 issue 和 PR 。
做了个书签管理工具，面向和我一样受"书签囤积症"困扰的知识工作者。
核心功能： • 本地 SQLite ，打开即用，无需注册 • AI 页面摘要（支持 OpenAI / DeepSeek / Ollama ） • 语义向量搜索（ pgvector ），按意思搜 • 知识图谱可视化 • 重复书签检测（精确匹配 + AI 近义匹配） • 链接健康扫描（ 404 检测） • 免费云同步（ Supabase RLS ，行级安全） • 一键导入 Chrome / Firefox / Raindrop • 12 款主题
技术栈：Wails(Go) + React + Vite + Tailwind + SQLite
免费，跨平台（ macOS/Win/Linux ），Homebrew 一键安装。
求 Star：github.com/blue-idea/linkit 欢迎 issue 和 PR 。
[分享发现] 写了个不用虚拟网卡、直接对进程 Hook 转发的 Windows 游戏 TCP 加速小工具
平时打外服网游或者私服（比如魔兽世界欧服），经常遇到 200+ms 延迟甚至频繁跳断。
试过市面上的加速器，大部分都要装 TUN/TAP 虚拟网卡改全局网关。平时电脑上跑着 WSL2 、Docker 、公司 VPN ，再开虚拟网卡经常路由冲突，改回直连还容易残留 DNS 污染。另外有些私服世界服跑在 8285 这种非标端口，规则代理漏掉端口就直接判定掉线。
为了解决这个问题，用 C++ 写了个轻量级的工具：直接通过 MinHook 拦截目标游戏进程（如 WoW.exe ）的 connect 和 WSAConnect 。
主要特点：
1. 零虚拟网卡：纯用户态进程注入，不装驱动，不改系统路由表，其他软件和网页完全不受影响；
2. 还原非阻塞套接字：在 Hook 内部完成 Socks5 握手后，自动恢复套接字原始的非阻塞模式并补发 FD_CONNECT 信号，避免游戏加载时主线程无响应；
3. 纯净流式转发：配合去除 padding 填充的 AnyTLS/TCP 隧道，避免破坏游戏 SRP 认证包长度；
4. 动态高位端口：启动时随机申请 50000+ 端口，避开端口占用；
5. 单文件无依赖：纯 C++ 编译，不依赖 Python 。
项目开源在 GitHub ，附带了完整的测试数据和服务端调优参考，欢迎体验交流： https://github.com/fun3588/game-tcp-speed
平时打外服网游或者私服（比如魔兽世界欧服），经常遇到 200+ms 延迟甚至频繁跳断。
试过市面上的加速器，大部分都要装 TUN/TAP 虚拟网卡改全局网关。平时电脑上跑着 WSL2 、Docker 、公司 VPN ，再开虚拟网卡经常路由冲突，改回直连还容易残留 DNS 污染。另外有些私服世界服跑在 8285 这种非标端口，规则代理漏掉端口就直接判定掉线。
为了解决这个问题，用 C++ 写了个轻量级的工具：直接通过 MinHook 拦截目标游戏进程（如 WoW.exe ）的 connect 和 WSAConnect 。
主要特点：
1. 零虚拟网卡：纯用户态进程注入，不装驱动，不改系统路由表，其他软件和网页完全不受影响；
2. 还原非阻塞套接字：在 Hook 内部完成 Socks5 握手后，自动恢复套接字原始的非阻塞模式并补发 FD_CONNECT 信号，避免游戏加载时主线程无响应；
3. 纯净流式转发：配合去除 padding 填充的 AnyTLS/TCP 隧道，避免破坏游戏 SRP 认证包长度；
4. 动态高位端口：启动时随机申请 50000+ 端口，避开端口占用；
5. 单文件无依赖：纯 C++ 编译，不依赖 Python 。
项目开源在 GitHub ，附带了完整的测试数据和服务端调优参考，欢迎体验交流： https://github.com/fun3588/game-tcp-speed