Marico's space

处理日期和时间这件事，看起来很简单，但当你盯着一个时间戳字段发愁，不知道为什么"最近30天"的查询结果总是莫名其妙时，就会意识到它其实相当棘手。日期和时间函数对于数据分析、报表生成以及任何涉及时间序列事件追踪的应用来说都至关重要——但不同数据库引擎之间的细微差异，连经验丰富的开发者也会栽跟头。 今天这篇文章，我们就来好好聊聊 PostgreSQL 和 MySQL 这两大主流数据库中最实用的日期/

说实话，日期和时间处理是 SQL 里最容易"踩坑"的领域之一。我见过太多经验丰富的开发者，被一个"最近30天"的查询折磨得一头雾水——明明逻辑看起来没问题，结果却莫名其妙。这个话题看起来基础，但数据库引擎之间的差异往往让人防不胜防。 这篇文章覆盖了 PostgreSQL 和 MySQL 两款最常用数据库的日期时间函数，全是实打实的实战案例。文章里的例子基于一个典型的电商数据库，包括订单表和用户表

这篇文章让我感同身受。作为一名在甲方企业干了多年数据库优化的工程师，我见过太多类似的场景：业务方天天催报表性能，工程师拼命加索引、加缓存，问题却像打地鼠一样按下葫芦浮起瓢。作者用“给奶酪刨丝”的比喻讲透了物化视图的本质——不是数据库太慢，而是我们在重复做同样的计算。这套从物化视图到汇总表、再到多级缓存的演进思路，其实就是 DBA 日常优化的一个缩影，很有参考价值。 先说说背景吧。 那是一个周二

帮一个连锁餐饮品牌做社交媒体同步，最初以为写个两百行的脚本就能搞定。真正上了生产环境才发现：那些本以为理所当然的部分一个都没有，反而多出来三个完全没预料到的东西。 把这些经验整理出来，供有类似跨平台同步需求的朋友参考。不透露客户信息，不贴核心代码，只说工程决策本身和背后的考量。 需求背景 客户同时运营 Instagram、TikTok 和 Facebook 账号。之前团队每周都是手动复制粘

这个项目里有个不太起眼但挺有意思的技术决策：三个目录网站共用一个 Claude Haiku 客户端。它放在 packages/shared/src/claude/index.ts，所有的 ETL 任务——模型摘要、游戏推荐、开源对比——都走这个入口。有趣的地方不在单例本身，而是提示缓存的设置和容错处理。 为什么非得搞个共享库 每个应用都有自己的 ETL 目录，里面有各自的 generate-

最近帮朋友排查一个自动化工具的问题，本来以为只是个例，结果顺藤摸瓜发现 LinkedIn 偷偷换掉了整个编辑器底层框架。这个故事挺有意思的，不光是对搞自动化的人有用，也让我重新思考了「平台依赖」这件事。 原文章讲的是 LinkedIn 从 ProseMirror 迁移到 Quill 导致自动化工具失效。技术细节很扎实，值得一读。 问题爆发 上周我刚给 MCP 服务修了 LinkedIn 的

说实话，微服务（Microservices）这个词在技术圈里被炒了这么多年，但真正能把「它解决什么问题」讲清楚的文章还真不多。要么讲得太理论，要么就是云里雾里的比喻讲一大堆。今天咱们就来好好聊聊，微服务到底解决了单体架构（Monolith）的哪些痛点。 先从一个特别接地气的例子说起吧。想象你开了一家奶茶店，一开始你一个人负责点单、做奶茶、收款，什么都是你说了算。客人少的时候，运转得还挺顺溜。但到

说实话，OAuth/OIDC 的测试一直是前端圈子的老大难问题。我见过太多项目要么跳过这部分测试，要么用一堆 mock 把测试变成了自欺欺人的游戏。这篇文章提出的思路让我眼前一亮——把协议逻辑和运行时 IO 彻底分开，这不仅仅是架构上的优化，更是一种思维方式的转变。 真正的痛点是什么 大多数 JavaScript 项目里的 OAuth/OIDC 集成，测试起来都非常鸡肋。常规操作就是 moc

做过实际 AI 产品的朋友大概都有过这种经历：你满怀期待地把一个「智能」功能交给用户，结果测试下来，同一个问题问了两次，模型给出了两个不同的答案；让它从合同里提取关键条款，它自信满满地编了一个条款编号；让它对比两三千条客户记录，它算出来的匹配率忽高忽低。这种不确定性在实际生产环境中简直是噩梦。 但这其实不是模型的问题。LLM（大型语言模型）本质上就是个「能说会道的推理引擎」，它本身就不是设计来保

从业这些年，我见过太多团队在生产环境中部署 LLM（大型语言模型）时被"随机性"折磨得苦不堪言——同一个问题问两遍，模型给出两个完全不同的答案；让它从文档里提取信息，结果里掺进了它自己"编"的知识。这种不稳定性让很多开发者对 LLM 在生产环境的使用心存顾虑。但其实，LLM 本身并不是什么洪水猛兽，问题在于我们有没有为它设计好合适的使用方式。 这篇文章讲的就是如何提升 LLM 的确定性——不是让