Marico's space

说实话，我第一次在自己的项目里接入 Google OAuth 的时候，被文档绕得有点晕。Google 的文档确实很全，但信息密度太大，很多关键细节埋得很深，比如为什么非得用 PKCE、access_type=offline 和 prompt=consent 这两个参数到底起什么作用。网上很多教程要么只讲一半，要么直接跳过了 refresh_token 这个环节，导致 token 过期后应用直接挂掉

多Agent系统（Multi-Agent System，MAS）的跨云部署确实是个很有意思的课题。我在实际项目中也踩过类似的坑——当系统从单机扩展到多云环境时，原本在本地跑得好好的同步调用会突然变得脆弱无比。LLM推理的不可预测延迟、企业网络里那些严格的NAT防火墙、还有容器漂移带来的状态丢失，每一个点都可能让你的Agent系统在生产环境里彻底失控。这篇文章提到的几个架构要点都相当实用，特别是异步

说到把应用跑在 AWS Fargate 上，我之前折腾过不少次。AWS 官方文档确实有点散落各地，很多教程也只教到"Hello World"就结束了，真正上线生产环境要的东西（HTTPS、自定义域名、负载均衡、自动扩缩容）基本都略过了。这篇文章把整个流程串了一遍，从把 Docker 镜像推到 ECR 到配好 CI/CD 流水线，30 分钟左右能搞定一个生产级别的部署。内容挺实在的，分享给大家。

处理日期和时间这件事，看起来很简单，但当你盯着一个时间戳字段发愁，不知道为什么"最近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）的哪些痛点。 先从一个特别接地气的例子说起吧。想象你开了一家奶茶店，一开始你一个人负责点单、做奶茶、收款，什么都是你说了算。客人少的时候，运转得还挺顺溜。但到