2026-第四十六周

该周报主要为各个地方内容的汇总整理

技术

让 TanStack Query 在各标签页间保持最新 - DEV Community

TanStack Query 默认每个标签页各自维护缓存，因此一个标签页中的变更不会自动同步到其他标签页；文章提出用 BroadcastChannel 广播“某个 queryKey 已失效”，让各标签页自行重新请求数据，而不是直接广播新数据。该模式也可用于跨标签页登出，但服务端会话失效仍是安全边界，广播只改善 UI 同步体验。

• 📌 核心问题：在标签页 A 修改变更后，标签页 B 的 TanStack Query 缓存仍是旧数据，除非重新聚焦窗口或触发重新请求。
• 📡 解决思路：通过 BroadcastChannel 发送“这个 queryKey 已失效”的事实，而不是发送新数据本身。
• 🔐 为什么不广播数据：每个标签页已有自己的鉴权、筛选条件、错误处理和请求逻辑，只发失效信号更简单、更安全。
• 🧩 实现方式：在 QueryClientProvider 内挂载一次 CrossTabInvalidation，监听 invalidate 消息并调用 queryClient.invalidateQueries({ queryKey })。
• 🔁 发送方行为：执行 mutation 的标签页先在本地失效查询，再广播给其他标签页；浏览器不会把消息回传给发送它的 BroadcastChannel。
• ⚠️ 刷新细节：只有活跃查询会立即重新请求；其他匹配查询只会被标记为过期，带 enabled: false 的查询不会自动重新请求。
• 🚫 无消息重放：后打开的标签页收不到之前的广播，只能依赖自身请求；若持久化查询缓存，数据新鲜度取决于 staleTime 和 gcTime。
• 🧱 查询键要求：queryKey 必须可克隆，只应使用字符串、数字、普通数组和对象，不能包含函数。
• 🚪 跨标签页登出：同样可广播登出事件，但应先结束服务端会话，再广播，再清理当前标签页；服务端拒绝后续请求才是真正的安全保护。
• 🛡️ 错过登出消息：关闭或冻结的标签页可能收不到广播，敏感页面应在重新回到标签页时显式校验会话，并在校验期间隐藏私有内容。
• 📚 文章还提供两个文档配方：TanStack Query 跨标签页失效，以及跨标签页登出。

工具

更新

设计

其他

程序员的悖论：小事

文章总结了作者多年编程中形成的若干“小习惯”，核心是提前准备、消除未知、用函数表达意图、保持命名与代码清晰，并通过抽象、重构和对细节的重视来提高开发效率与代码可靠性。

• 🛠️ 编码前尽量做好准备工作：环境、磁盘、外设、家具，以及日志、错误处理、配置、密钥和安全基础都应先就绪，减少后续干扰。
• ❓ 不要留下疑问：如果不知道“做什么”或“为什么做”，现在就查清楚，不假设、不忽略、不拖延。
• 🧩 多用函数给代码块命名：函数名应简洁明确，通常是一个动词作用于输入名词，避免晦涩命名；函数也可替代注释，便于审查、分解和重构。
• 🧱 拆分前置条件与核心逻辑：把断言、错误处理、小计算等放在函数开头，让核心逻辑不被干扰；每个后续要用的数据都放进独立变量，相关逻辑聚在一起。
• 🔁 不要害怕大幅重构：发现方向错误或逻辑颠倒时立即修正，不要因为已投入时间而继续硬撑，否则会变成时间黑洞。
• 👀 重视可读性细节：代码要便于几个月后自己回看，也能让隐藏问题更容易暴露。
• 🏷️ 对命名保持敬畏：认真找到技术层面和业务领域中真正准确的名称；错误命名会吸引 bug，甚至长期传播造成困扰。
• ➰ 谨慎对待循环：能不用就不用，循环要拆出来并能证明其必要性；循环往往是性能问题的源头。
• 📈 不要硬磨大量样板代码：如果感觉要用 50 小时重复劳动，就退一步寻找更好的抽象或泛化方式。
• 🧠 不要耍小聪明，要聪明而清晰：显式写清楚通常更安全，语法糖可能变成以后会踩到的地雷。
• 🎯 代码不是系统本身，但它是控制系统行为的关键：代码规模越大，风格、格式、组织、一致性和细节越重要；要追求精确，以便在关键时刻可靠地完善代码。

面向渐进式自主的委托设计

AI 智能体的自主权不应是一次性开启的开关，而应像培养新人一样逐步授予：先判断任务是否适合交给智能体，再通过小步协作、过程观察和有限派出建立信任；自主权应像旋钮一样可调，并始终保留监督、干预与回退机制。

• 🎚️ 自主权是渐进旋钮，不是二元开关：根据实际表现逐步扩大授权，避免第一天就完全放手，也避免永久人工审核。
• 🧑‍⚖️ 先判断再委托：让用户决定哪些工作值得自动化、哪些任务适合交给智能体，而不是由软件强行接管现有流程。
• 🧪 用小型、可见的步骤测试：让智能体在关键决策点请求确认，支持人机协作，而不是提交后长时间等待一个难以检查的结果。
• 👀 展示过程而不仅是结果：公开智能体的推理、意图和中间状态，让用户能检查进度、及时停止并降低风险。
• 🔁 为失败轮次设计：保留操作日志、可逆操作和手动路径，允许用户随时把自主权调低。
• 🛫 逐步“派出”智能体：信任增加后，可延长自主运行间隔、减少接触点，但仍要允许用户陪伴、查看和介入。
• 🧑‍✈️ 自主不等于孤立：像新人出差有人陪同一样，智能体执行任务时也应让用户能看到其工作位置并随时接管。
• 🧱 产品设计应体现授权层级：界面要反映用户授予的自主程度，显示智能体正在操作的范围，支持监督和回退。
• 💡 结论：用“判断、挑战、观察、派出”的模式设计智能体产品，让用户有时间逐步建立信任，并在信任不足时随时收回自主权。