码厩开发者笔记

#1297 如何进行一次成功的公开演讲

根据阮一峰《公开演讲的窍门》和国外博主《My experience as a first time speaker》（英文原文）总结。

1. 内容只占30%，表达占70%。
   演讲本质上是一场现场表演。除了内容，还要利用语气、语速、停顿、表情、动作和手势吸引观众，让现场变得有趣。

2. 从简单的话题开始。
   第一次演讲不要挑战过于复杂的主题。选择自己熟悉、规模可控的话题，把更多精力放在表达、节奏和舞台表现上。

3. 充分准备，并从低风险场合开始练习。
   演讲稿、PPT、案例、语调、节奏和时间都应反复练习。同时可以从小型分享、公开活动、开放麦等场合开始，逐步积累舞台经验。

4. 技术演讲遵循 Why → How → What。
   先讲为什么值得关注，再讲解决问题的大致思路，最后才是具体实现。技术细节可以少讲甚至不讲，避免把演讲变成文档朗读。

5. 自信不是想出来的，而是练出来的。
   没有人能够凭意志直接获得自信。真正的自信来自一次次面对并克服恐惧，没有捷径，只有不断降低挑战难度。

6. 接受紧张，并把它转化为兴奋。
   再充分的准备也无法彻底消除舞台紧张。与其试图消灭紧张，不如把这种压力转化成兴奋，让它为你的舞台表现提供能量。

7. 开场最难，坚持把第一句话说出来。
   上台后的前几句话通常是最困难的。一旦成功开口并进入自己的节奏，紧张感往往会迅速下降，所以开场尤其值得反复练习。

8. 不必因为能力不足而拒绝登台。
   公开演讲吸引的往往是自信的人，而不一定是能力最强的人。你不需要成为专家，只要有真正想分享的话题，就有登台的理由。

#1296 100米生物红外探测

看了一些户外露营的视频，我突然想到：如果半夜有野兽悄悄靠近营地，该怎么办？夜间肉眼看不见，普通摄像头也很难发挥作用。于是我开始琢磨，能不能用红外成像做一套低成本的户外安防系统，在黑暗中提前发现靠近的人或动物。

如果目标是100米范围内发现热目标，首先要区分 PIR、近红外 NIR 和长波红外 LWIR。它们虽然都属于红外技术，但工作原理完全不同。

1. PIR 热释电传感器：普通 HC-SR501 主要检测人体红外辐射的变化，实际有效距离通常只有十几米。
   单纯增加菲涅尔透镜，也无法把普通 PIR 简单扩展到可靠的100米探测，因此更适合近距离移动目标告警。

2. 近红外 NIR：思路是 普通/星光级摄像头 + 850nm/940nm红外补光灯 + 长焦镜头，本质上就是“黑白夜视”。
   850nm通常具有更高的成像效率，但红外LED可能产生微弱红光；940nm更加隐蔽，但相同功率下通常成像距离更吃亏。
   通过合适的摄像机、红外补光和长焦镜头，可以实现100米级夜间观察。但它属于主动照明，不是热成像。

3. LWIR 长波红外热成像：通常工作在约 8～14μm，直接接收人体、动物等目标自身产生的热辐射，因此不需要可见光或红外补光。
   MLX90640（32×24）可以用于低成本热目标实验，通过合适的LWIR镜头，在良好环境和光学条件下尝试探测100米量级的人体热异常。
   但32×24分辨率非常有限，更适合判断“是否存在疑似热目标”，无法可靠区分人、狗、野猪等目标。
   如果要求100米处获得更好的目标检测、定位和粗分类能力，应使用 160×120、256×192、384×288甚至640×512等更高分辨率热成像机芯，并匹配合适焦距的LWIR镜头。

因此可以简单理解为：

• PIR：近距离移动目标告警；
• NIR：主动红外照明，实现100米级夜视；
• LWIR：被动接收目标热辐射，实现100米级热目标探测。

注意：100米不是某种传感器的固定能力，实际效果取决于探测器、镜头焦距、目标尺寸、目标与背景温差以及天气条件。

一句话总结：NIR是“给目标打红外灯再拍下来”，LWIR是“不打灯，直接看目标自身的热”。

“热成像周界安防系统 / 热成像周界防范系统 / 双光谱周界摄像机 / 热成像全景光电系统”

其中最有意思的是热成像全景光电系统。
包含：LWIR机芯 + 长焦锗镜头 + 可见光摄像机 + 云台 + AI识别 + 自动跟踪 + IP66/IP67户外结构 + 网络接口 + 报警接口

例如国内燧石技术的 SilentW-U12，就是典型的红外全景雷达/热成像周视系统：采用8～14μm LWIR探测器，360°连续扫描，2秒左右完成一圈，同时支持人、车、船等目标识别。
海康微影也有专门的热成像全景光电转台产品线，用于远距离周界监控。
一套设备完成360°扫描、热目标发现、目标跟踪和可见光确认。

#1295 Google Workspace 的域名校验：一个正则黑名单引发的误伤

注册 Google Workspace 时，作者输入公司域名后，却收到“请输入有效域名，而不是邮箱服务商”的提示。域名本身没有任何滥用记录，Google 官方也无法解释原因。联系客服后，经历了换浏览器、换设备、录屏、提交工程师等流程，最终得到的建议竟然是“换一个域名”。更离谱的是，社区中还有其他正常域名遭遇同样问题，甚至包括乌克兰经济部使用的 me.gov.ua。

#1294 预测台湾统一战争

台湾和平统一目前面临较大阻力，岛内政治、社会认同以及外部势力介入，使和平解决的空间不断受到压缩。如果两岸长期无法通过政治方式达成共识，且大陆综合实力和军事准备进一步增强，最终通过战争实现统一的可能性可能高于和平统一。届时真正的挑战不仅是军事胜负，还包括战后安全、社会稳定和长期治理。

#1293 SQLite 适用一切场景

在 Dr. Raphael A. Bauer 发表《PostgreSQL for Everything》之后，JoeCode 发表了一篇《SQLite for Everything》调侃式回应（作者强调自己同样喜欢 PostgreSQL，但认为 SQLite 被严重低估）。
参考：PostgreSQL 适用一切场景

作者的核心观点：很多团队为了"看起来像生产系统"而引入的一整排基础设施（搜索、队列、缓存、向量库、图库、微服务……），在大多数项目里其实一个 SQLite 单文件就能顶替。
开发新项目的时候，先判断"它能跑在单机+单文件上吗"——能就先上 SQLite，真撞到写并发或分布式天花板再换重的。大多数业务比开发者以为的更晚才会撞墙，而期间你省掉的是大量运维工作。

SQLite 三大底层优势

• 坚如磐石：2000 年发布，公有领域（public domain，不是普通开源），MC/DC 100% 分支覆盖、测试代码是库代码的约 500 倍，官方支持承诺到 2050 年；手机/浏览器/汽车/飞机里都在跑，部署量超过其他数据库总和。
• 零运行成本：没有 daemon、没有端口、没有 Docker。已绑定在 Linux/Python/Go/Rust/.NET/Android/iOS 里；测试用 :memory: 微秒级拉起，和生产同库同二进制。
• 极大简化 IT 拓扑：它不止是 RDBMS，还能当全文搜索引擎、文档库、队列、时序库、向量索引、缓存、文件格式、图存储——"少装一个服务"就是少一个要监控/升级/背锅的系统。

"SQLite 替代 X" 对照表

SQLite 的天花板

• 不支持并发写入：高并发写入（每秒几万条以上）会卡在写锁；多机多写、跨机房分布式写不适合原生 SQLite。
• 规模边界：超 TB 级数据、百万点/秒时序、需要用户/角色级 ACL 的多租户 SaaS，应换 Postgres/MySQL/ClickHouse 等。
• 扩展方案：Litestream（WAL 流式备份到 S3）、LiteFS（分布式读）、Turso / Cloudflare D1 / rqlite（托管 SQLite）可缓解部分限制，但不改变单写本质。

#1292 PostgreSQL 适用一切场景

这篇文章（Dr. Raphael A. Bauer 的《PostgreSQL for Everything》）的核心论点是：PostgreSQL 不是万能答案，但能覆盖你想象中多得多的场景；在中小规模下，先用 PG 统一数据层，遇到真实瓶颈再换专用系统，是更省维护成本、更快交付的架构选择。

PostgreSQL 凭借“老牌稳定 + 现代特性 + 插件生态”，在初创和中型业务里可以一个数据库顶住搜索、文档、队列、时序、向量、缓存、层级数据等多套中间件；它的真正价值不是性能碾压专用库，而是用更低的运维与认知成本，让你把时间花在业务功能上。

一、为什么选 PostgreSQL：三个底层优势

• 成熟且持续进化：1996 年至今，bug 被长期打磨；社区向后兼容地加现代特性（CTE、分区、JSONB、逻辑复制等）。
• 部署与生态极简：本地 brew/apt/docker、Testcontainers 测生产一致性、云厂商一键托管，维护成本极低。
• 可扩展性强：原生能力 + 插件（TimescaleDB、pgvector、pgai、LTREE 等）把多种数据模型收进同一个 ACID 库。

二、PG 能“单库替多中间件”的场景清单

作者用自己 CTO 生涯的实战说明，以下场景不必急着引入专用组件：

作者强调：这些都是“先 PG 起步”的策略，不是否认专用系统——当吞吐/并发/规模真正打满时，再切 Kafka、ClickHouse、Redis 不迟。

三、架构哲学：用“无聊”换速度

• 少零件 = 少同步 = 少漂移：避免 ES 与 PG 双写、Mongo 与 PG 对账这类管道腐烂。
• 团队认知负担下降：一套 SQL 技能覆盖关系、文档、搜索、队列、时序、向量。
• 决策顺序建议：新需求来了先问“PG 能不能做”→ 能做就用 → 压测出真实瓶颈再引入新技术，而不是反过来为“技术新鲜感”买单。

这篇文章带来很好的启发：PostgreSQL拥有多模型存储能力，原生支持文档（jsonb）、轻量缓存、全文检索、向量检索、队列表等场景。在不少业务场景下，可以优先基于PG实现相关能力，避免盲目引入新的中间件，降低系统复杂度。

但我不认同将其作为一套可直接落地的生产级通用方案，存在明显边界约束（架构收敛不能牺牲稳定性）：

1. 把缓存、海量文档等旁路能力并入同一套业务主库，存在严重稳定性风险。
   业务主库承载核心交易、用户等核心数据，属于不可丢失的Source of Truth。缓存、高频半结构化读写具备流量大、允许降级、可丢失的特征，二者共用数据库会造成资源互相抢占、故障域合并；缓存流量抖动、jsonb频繁更新引发的膨胀与IO压力，会直接拖慢核心业务SQL，极端场景导致全站故障。
2. 如果为了替代Redis、MongoDB等而新部署一套PostgreSQL，无法降低架构成本，反而是牺牲性能、增加运维负担。
   新增独立PG集群会带来额外的机器、运维、监控、高可用成本，相比直接引入轻量专用组件，总体成本更高，违背“简化架构”初衷。

适用场景：

1. 新项目、初创项目、MVP阶段：快速迭代优先，减少中间件维护成本，等业务出现真实瓶颈后再拆分专用组件；
2. 内部系统、后台管理平台、低频运营系统：无C端高并发压力，可用性要求适中；
3. 边缘业务、工具类、小型独立服务：规模有限，无需搭建复杂中间件体系。

#1291 同样吃苦，山河四省省吃俭用、云贵川渝活在当下，为何苦难传承出的生活态度截然不同？

知乎上看到这个问题，还让我一征，好像是这么回事，浏览了网友的回复更让我觉得有点道理：两种观念差异，根源在于两地先民承受的苦难模式截然不同，因此造就两种生存哲学。

山河四省地处平原，土地广阔却人多地少，常年要应对旱涝灾害，苦难细碎、漫长、持续不断，如同钝刀割肉。日子尚可维持，但未来充满不确定性，今年丰收不代表来年风调雨顺。长久以来，人们依靠积攒粮食与钱财抵御长期风险，省吃俭用不是吝啬，而是对抗持续性困境的生存智慧。这份未雨绸缪的观念代代相传，叠加当地激烈的教育、就业竞争，让储备资源、为长远谋划成为普遍选择。

云贵川渝多山地，耕地零散，地震、山洪、泥石流等灾害突如其来，属于毁灭性的突发大难。这类天灾难以依靠平日省吃俭用积攒的物资规避，人们渐渐意识到，很多无常无法提前防范。既然无法预判明天，便不愿亏待眼前，有条件就好好享受生活，把开销优先投入当下的饮食与欢愉。

需要厘清的是，这种区分并非绝对标签。山河四省遇上喜事也愿意大方消费；云贵川渝民众同样懂得精打细算，只是消费重心偏向当下生活。

两种生活态度，都是祖辈在苦难之中摸索出的生存选择。一方依靠积蓄抵御绵长困境，一方选择拥抱当下对抗命运无常，没有高下之分，都是普通人应对生活磨难沉淀下来的生活哲学。

#1290 MicroLighter 代码高亮库

把代码高亮从 DOM 层搬到 CSS 渲染层的 2 KiB 方案

#1289 实现 SSH 安全防护的方案

《Why I close SSH port 22 entirely (and what I use instead)》作者主张：

1. 彻底关闭公网 SSH 22 端口，而非仅靠密钥登录或 fail2ban。
   传统端口敲门（port knocking）用明文序列开端口，易被抓包重放。
2. 改用 fwknop 单包授权（SPA）：客户端发一个 加密+HMAC-SHA512 签名的 UDP 包，内含时间戳与一次性计数器。
   1. SPA 包加密防窃听、签名防伪造、时间戳/计数器防重放
   2. 加密密钥与 HMAC 密钥分离，一个负责"别让人偷看"，一个负责"别让人造假"
3. 服务端 fwknopd 校验通过后，临时（如 120 秒）向 iptables 插入仅放行客户端 IP 的 22 端口规则，超时自动回收。
4. 配合 ~/.ssh/config 的 ProxyCommand 可让 ssh server1 透明敲门。
5. Tailscale 加密隧道作兜底，确保万一 SPA 机制失效还能成功登录机器。

这个方案不是“换端口藏起来”，而是默认全拒+密码学鉴权，把攻击面缩到仅收 SPA 的 UDP 口，好处就是对扫描器而言 22 端口始终 filtered，无 banner、无 RST，OpenSSH 零日无法被触及。

#1288 Golang 新提案，拟在标准库新增 crypto/passkey​ 包

关于Passkey 的介绍参见 《Passkey 无密码登录》。

前 Go 密码学负责人 Filippo Valsorda 提交 golang/go#80663 提案，拟在标准库新增 crypto/passkey 包，用“无状态、无回调、无接口”的极简服务端 API，把中小型网站接入 Passkey（WebAuthn 可发现凭据）的门槛降到最低。

核心设计有三块。一是 passkey-record 规范：把认证器数据、transports 等编码成类似 PHC 密码哈希的单行不透明字符串（如 $webauthn$v=1$...），存库时当黑盒文本即可，支持跨语言、跨库迁移。 二是 存储模型简化：数据库只需 user_id + record 两列、按 user_id 建索引，不对 credential_id 建唯一索引——凭据永远先按用户查再逐条比对，从根上规避跨账号主键碰撞攻击。 三是 流式无状态工作流：RelyingParty 是纯配置对象，注册走 NewRegistration→前端 navigator.credentials.create→Register 存串；登录走 NewLogin→ParseResponse 取 UnauthenticatedUserID（验签前不可信，仅用于查记录）→Login。

关键安全取舍：弃用回调（吸取 GO-2024-3321 教训，避免未验数据流入应用判断）、强制单 Origin 配置（多源需建多个 RP 实例，防跨站断言重放）、User ID 用 crypto/rand.Text() 生成随机不透明串、不校验 attestation 与签名计数器，专为消费级 95% 场景减负。

提案仍处评审期，未进正式版本，但信号明确：Passkey 接入正从“懂协议”降级为“按 user_id 存一个字符串”。