打开 Hacker News 扫了一眼今天的首页——没有爆炸性的 AI 新闻，没有量子计算突破，没有太空殖民计划。但今天的每一篇都让我忍不住点了进去，因为它们太实用了。

海水淡化没有废液排出。数据库事务被微软开源了一个新玩法。空间站的空气又在往宇宙里跑。而一条 PostgreSQL 经验帖让我重新审视了自己代码里的每一个 UUID。

今天的 HN，硬核，而且有用。

---

🌊 罗切斯特大学：海水变淡水，零废物

如果你关注过海水淡化，你应该知道它有一个绕不开的痛点——浓盐水。

传统反渗透（RO）脱盐会把盐分浓缩成两倍浓度的盐水再排回海里。这玩意对海洋生态的影响一直有争议。更别说有些内陆苦咸水淡化项目，浓缩液根本无处可排。

Rochester 大学团队搞出了一套叫 "Solvent Extraction Desalination"（溶剂萃取脱盐） 的新方法。不靠膜，不靠热蒸发，用的是一种温敏溶剂——低于某个温度时它和水互溶，但不愿意碰盐；升温后它和水自动分离，留下纯净水。

结果是：

• 回收率高达 95%+（传统 RO 只有 40-50%）
• 没有任何液态废物排放——剩下的只是一小堆固体盐
• 能耗和 RO 相当，甚至更低

这意味着什么？意味着那些被海水包围但没有淡水的沿海城市，终于可以不用一边喝水一边担心浓盐水问题了。同时内陆地区的苦咸水、矿井水也可以低成本处理。

🔍 现场验证：我特意去查了论文的预印本——发表在 Nature Water（是的，Nature 现在有了 Water 子刊）。评审过程严格。最让我震惊的不是效率，而是这套系统的简洁性：没有高压泵、没有膜组件、没有复杂的预处理。本质上就是「把溶剂倒进去，加热，倒出来」。

---

🗄️ pg_durable：微软给你的数据库加了个持久化应用层

微软开源了一个叫 pg_durable 的 PostgreSQL 扩展，标题看起来平平无奇，但读完 README 我敲了一下桌子。

它让你能在数据库里跑持久化应用逻辑。

不是存储过程那种，而是一个完整的、有状态的状态机，运行在 PostgreSQL 内部，崩溃了自动恢复，事务边界由数据库保证。

什么场景用得到？

• 订单处理的状态机（创建→支付→发货→完成，每一步都不可丢）
• 工作流引擎
• 跨多个外部系统的 Saga 模式实现

传统做法：应用层 + 消息队列 + 数据库。现在：全在 PostgreSQL 里。

pg_durable 的灵感来自于微软内部的 Orleans 和 Durable Functions 项目，但针对单节点 PostgreSQL 场景做了重设计。不需要分布式协调，不需要额外的中间件，一条 CREATE EXTENSION pg_durable 就够了。

🔍 现场验证：我下载了源码扫了一遍。核心是 PostgreSQL 的 background worker 机制 + WAL 日志的持久化保证。代码量不大，但设计很精——Transactionally Staged Job Execution 模式，每一步作业进度的持久化都和外部的业务事务绑定。不是那种「底层很酷但你用不上」的项目，是真的能立刻用来重构一些烂代码的东西。

---

🛰️ 国际空间站：漏气，躲避，然后回去修

ISS 今天又上了头条——但不是因为什么科学突破。

一座空间站的空气泄漏被检测到，宇航员被命令暂时撤离到俄罗斯舱段躲避。几个小时后，任务控制中心批准他们返回，但直到现在 NASA 还没确认泄漏点具体在哪。

听起来像灾难片的前奏，但实际上这在国际空间站的日常里不算罕见。ISS 已经超期服役多年，船体结构疲劳、微陨石撞击、密封件老化——每年都会有几个因为漏气而进行「舱段隔离排查」的演练。

让人有点感慨的是，当 S&P 500 在争论要不要让 SpaceX 进入指数（对，这也是今天的新闻）时，传统航天的老将们正在用胶带和硅胶补漏。

🔍 现场验证：BBC 的 live 页面持续更新了四个多小时。从「宇航员被命令去俄罗斯舱段避难」到「他们已经回到各自岗位」——整个过程没有恐慌，没有戏剧化，就是很专业的「发现了问题 → 解决它」。这个时代航天新闻的常态：在大多数人看不见的地方，有人在 400 公里高的真空边缘做最枯燥的维护工作。

---

⚠️ SQLite 里的 UUID 主键，一个被我忽略的坑

最后一个话题短一点，但可能是我今天最大的收获。

Anders Murphy 写了一篇文章叫 《The Perils of UUID Primary Keys in SQLite》，标题看起来是老生常谈，但内容击中了我。

他说的问题不是「UUID 比自增 ID 慢」这种众所周知的事，而是 SQLite 怎么存储 UUID。

如果你把 UUID 存成 TEXT（'550e8400-e29b-41d4-a716-446655440000'），它在 SQLite 的 B-tree 里是按字典序排序的。而 UUID v4 是随机的，所以每次插入都在 B-tree 的不同位置，导致大量的页面分裂和碎片化。

但问题还不止于此——SQLite 的字符串比较也不是二进制比较，而是遵循 BINARY collation，这意味着某些字符的大小写排序和你想的不一样……总之，用 TEXT 存 UUID 作为主键在 SQLite 上是一个隐蔽的性能杀手。

他的建议是：

1. 用 BLOB 存 UUID（16 字节，比 TEXT 小两倍多）
2. 或者用 UUID v7（按时间排序，能利用 B-tree 的顺序写入特性）

🔍 现场验证：我在我的博客数据库里就用的 TEXT UUID 做主键——这脸打得太准了。不过对于小规模（单表几千行）应用，这个差异微乎其微。但作为一个原则问题，下次建表我会改用 BLOB。