从头了解 Redis 缓存种类与常见灾难
Redis 是十分常见的 In-Memory 资料库，工作上时不时会碰到它但很少仔细从头了解它，所以透过撰写重现一些案例达成更深刻的理解。缓存就是把常存取的资料放在能够快速获取的地方，缺点是记忆体不像硬碟适合长久保存资料，但不管是提高速度、降低延迟、降低负担或减轻成本⋯⋯缓存都是很棒的选择。
Redis 是十分常见的 In-Memory 资料库，工作上时不时会碰到它但很少仔细从头了解它，所以透过撰写重现一些案例达成更深刻的理解。缓存就是把常存取的资料放在能够快速获取的地方，缺点是记忆体不像硬碟适合长久保存资料，但不管是提高速度、降低延迟、降低负担或减轻成本⋯⋯缓存都是很棒的选择。
相较于 C 读取未定义数值的变数会造成安全漏洞或崩溃，或是动态语言如 JavaScript 没有数值型别初始化的问题，Go 的设计上就自动赋予了确定意义的数值避免出错与创建即可使用。具体来说在例如使用 json 反射的标签中 `omitempty` 也正是运用了 Zero Value 的概念来判断。
虽然在 AI 出现之前很难想像，但 2026 年工作上我已经很少「手写程式」而是透过 AI 更有效率的辅助开发，我相信在 AI 百家争鸣的时代不用特别执着用哪个模型或工具，挑个最新顺手的免费方案就够了，未来模型只会更便宜更有效率。
前端测试主要重点在与浏览器打交道（Jsdom、Headless Browser）且通常只与单一后端进行沟通，而后端测试则是面临截然不同的难题：分散服务与状态。这篇文章介绍实战上我如何透过 Testcontainers 创建 Docker 测试环境来达成完整的后端整合测试流程。
AES（Advanced Encryption Standard）是最广泛使用的对称加密，HTTPS/TLS、Wi-Fi（WPA2/3）、全硬盘加密（BitLocker、FileVault）……通过理解 AES 如何运作有助于了解现代安全加密如何实践。
不同网站的密码需要管理，不仅容易忘记，也存在被窃取或重复使用的风险。如果只需要扫描指纹或使用面部识别，就能立即完成注册与登录——这正是 FIDO（Fast IDentity Online）所推动的“无密码身份验证”愿景。
最近在写 Go 测试时发现官方与社群中有一种大力推崇的惯例：TableDrivenTest，我一直以为测试应该要保持简单愚蠢，但这种做法让我想到程式人的三大美德之一：「懒惰」。可能是因为这种模式通常只是测试框架包装下的方便手段，而 Go 社群文化下人人对于追求简单程式有一种莫名的执着。
纪录近期从 JavaScript 迁移到 Go 的过程中实践 Set 资料结构的方式。先前代码使用 JavaScript Set 来实现不重复资料定义，但在 Go 语言当中并没有实践 Set 资料结构，但我们可以透过改造 map 来实践。
纪录使用到其中一项 Go 1.16 的 embed 功能，可以把任何档案在编译时就包进去，进而不用烦恼路径与环境问题。如果资料需要在 runtime 被修改，那就不适合使用 embed，但如果它是「版本的一部分」，那 embed 是更安全的选择。
P 与 NP 用来描述解决问题的难度所需的时间为：polynomial time 或 non-deterministic polynomial time。将问题分类为 P 或 NP，有助于理解一个问题是否有可能在合理的时间内被解决——即执行时间不会随着输入规模的增长而爆炸性膨胀。
先前探讨到：什么是 Feature Flag 以及它解决什么问题？了解 Feature Flag 存在的价值后，今天了解更多关于 4 种类型的 Feature Flag 以及实战上的用途。不同目的的 Flag，在设计方式、生命周期、动态程度与管理策略上都有明显差异。
我一直觉得事情可以保持简单就好，有问题改程式码或环境变数切换就好，何必导入更复杂的套件管理与第三方服务呢？但真实情境当问题发生时不会有空闲慢慢部署与除错，就有必要透过更完善的 Feature Flag 规划来降低推送功能的风险，也能减少心脏病发作的机率。
通常有些规模的专案会透过架构分层的方式来管理，而近期在研究如何更好的透过「依赖注入」替换模块并实现更干净的测试。架构分层的概念可以参考之前写过的：Express.js 入门建构 MVC 范例。我上传了 go-gin-testing-todos 范例透过 DI 实践测试架构。
从 JavaScript 转写 Go 我其实还是不太熟悉 Go 如何模组化处理代码，虽然它们有大致相似的地方，但使用体验感觉非常简单甚至到简陋的程度，当然简单并不意味着「容易」或「没用」，Go 简单且固执己见的哲学在各方面都感受得到。
很早以前接触资料库就有听说过「N+1 问题」，不过一直没有写下笔记认真思考过一次，这次撰写问题成因与详细解方与图表。透过：资料结构设计（去正规化）、在 DB 层完成关联资料查询、批次查询并在应用层组装、ORM ODM Eager Loading 来解决。