TLDR:

• x-cmd 改用 Apache 2.0 协议发布。
• minimax 模块默认模型升级为 Minimax-M2.5。
• claude 模块新增 use 命令，支持全局和项目级别默认模型切换。

🚀 X-CMD v0.8.3 更新详情

x-cmd

🎉 各位 X-CMD 的朋友，祝大家马年大吉，万事如意！🐴 🎊 X-CMD 越用越顺，vibe coding 越来越爽。

新年新气象，从 v0.8.3 开始，我们将采用 Apache 2.0 协议发布 X-CMD ；企业用户可以更自由地使用和集成 x-cmd。

Happy coding ~ 🐮🍺

minimax

minimax 模块默认模型升级为 Minimax-M2.5。

春节那波，kimi、glm-5、minimax 都发布了最新模型。minimax 很良心，升级没加价，我们正在不断试用 M2.5。

示例：

x minimax --cfg

claude

claude 模块新增 x claude use 命令。

如果你只用一个厂商，设成默认后直接打 claude 就行，比 x claude mm 更省事。

项目级别可以用 -p（--project），只影响当前项目：

• x claude use glm
  → 写入 ~/.claude/settings.json（全局）
• x claude use -p mm
  → 写入 .claude/settings.local.json（项目，优先于全局）

想换回来？x claude use claude。我们也保留了前缀模式：

• x claude mm 使用 minimax
• x claude glm 使用智谱 glm-5

示例：

# 全局默认用智谱
x claude use glm

# 项目级别用 minimax（优先于全局）
x claude use -p mm

# 换回官方 Claude
x claude use claude

# 前缀模式
x claude mm hello
x claude glm hello

⬆️ 如何升级

现有用户可以通过以下命令快速切换至最新版本进行体验：

x upgrade

如果你没有安装 x-cmd, 只需要打开你的终端:

eval "$(curl https://get.x-cmd.com)"

x-cmd 是一个一站式的命令行工具集，其强大的功能可以为人类用户和AI共同使用。它还简化了很多工具的安装方法。
马上安装，让 x-cmd 协同 AI 成为你的最强助手，实现生产力翻倍！

🤝 开发者反馈

如果您在自定义配置或代理设置中遇到任何疑问，欢迎前往 GitHub Issues 提交反馈，共同完善 X-CMD 生态。

大家好！我是 Hugo，数字游民一枚，聚焦 AI 轻创&OPC&DAO。
\
在信息如洪水般冲刷、AI 以指数级速度重塑知识图景的今天，我们每个人都面临着庄子两千多年前就已洞见的困境：“吾生也有涯，而知也无涯。”
\
当 ChatGPT 秒成论文，算法编织的信息茧房包裹全球，我们比任何时候都更需要追问：在有限的生命里，我们究竟该追逐什么？

一、AI 时代的认知困境：当“信息投喂”取代“主动求索”

我们正身处一个历史性的转折点。根据《全球数字阅读报告》，人类日均接触屏幕时间已达 6.2 小时，其中 78%的信息获取依赖算法推荐。这种“投喂式”阅读导致了三重认知异化：

• 注意力的碎片化：TikTok 式的短内容培养了“滑动拇指的一代”，深度阅读能力正以每年 12%的速度衰退。频繁切换信息源会削弱大脑聚焦复杂议题的能力。
• 思维的单向度化：算法通过“协同过滤”不断强化我们的既有认知，使波普尔所言的“猜想与反驳”的科学精神，沦为数据茧房中的自我循环。长期使用推荐算法的用户，其观点多样性较十年前下降了 47%。
• 意义的空心化：海量信息如洪水冲刷，却难以沉淀为托克维尔笔下“心灵的习惯”。我们面临着鲍德里亚所说的“信息透明性暴力”——过量的信息反而导致了意义生产机制的瘫痪。

更深刻的危机在于，生成式 AI 正在消解我们的认知主体性。当 AI 能模仿但丁的笔触创作十四行诗，当 83%的大学生无法区分 AI 生成的哲学论文与人类学者的作品时，康德所言的“理性自律”面临前所未有的挑战。我们不再需要通过艰苦的思考来建构认知，而是依赖算法直接获取“答案”，苏格拉底“产婆术”所代表的批判性思维传统正在被摧毁。

二、庄子的古老智慧：在“有涯”与“无涯”之间找到“道”

正是在这样的背景下，庄子《养生主》的智慧显得尤为振聋发聩。“以有涯随无涯，殆已！”——用有限的生命盲目追逐无限的知识，只会让人精疲力竭。庄子的原意并非反对求知，而是反对那种耗尽心力、不加甄别的做法。

他提出的解决方案是“缘督以为经”。“督”指自然中虚之道或事物的规律；“经”指常法。意思是顺应自然的规律作为处世的常法，如此方能“保身、全生、养亲、尽年”。这与道家“天人合一”、“道法自然”的核心思想一脉相承。

庄子启示我们，知识的关键不在于多寡，而在于是否合“道”（真理）。合乎“道”的知识越多越好，违背“道”的知识越少越好。因此，真正的求知过程，既是增加知识，更是鉴别和剔除悖道知识的过程。那些合乎“道”的知识，我们称之为“智慧”——它是本源，是底层逻辑，可以举一反三、触类旁通，真正做到以不变应万变。

三、经典阅读：抵御技术异化的最后堡垒

在算法主导的时代，我们比任何时候都更需要回归经典阅读。经典作品所蕴含的人类思维精华、情感深度与价值判断，构成了抵御技术异化的最后堡垒。

• 经典是时间的筛子：经典之所以成为经典，在于其经过了时间维度的残酷筛选。艾柯指出，经典文本具有“开放性结构”，每个时代的读者都能从中发现新的意义。例如《论语》，朱熹读出“格物致知”，王阳明看到“知行合一”，而我们能在春秋乱世中找到应对现代性危机的启示。这种跨时空的对话能力，正是经典抵御算法同质化的核心优势。
• 深度阅读锻造认知肌肉：神经科学研究表明，阅读复杂文本时，大脑的默认模式网络会被激活，促进抽象思维与共情能力的协同发展。阅读托尔斯泰的心理描写时，大脑会产生类似真实社交的神经活动。这种“费力的阅读”，如同肌肉锻炼般强化着人类的理性能力。哈佛教育学院的实验显示，持续一年的经典阅读训练，能使学生的逻辑推理和抽象思维水平提升 31%。
• 经典是人性的镜像：在技术异化日益加剧的今天，经典文本成为守护人性的最后阵地。AI 可以生成道德准则，却无法理解陀思妥耶夫斯基笔下“苦难的救赎”；可以计算最优策略，却无法体会《庄子》“庖丁解牛”中蕴含的自由境界。这种对人性复杂性的深刻理解，正是防止人类被技术同质化的精神抗体。

四、数字游民的生存逻辑：求道经典，驾驭 AI

作为数字游民，我的生存逻辑正是基于此：
\
求道经典智慧，传承驾驭 AI 时代的不变心法；
\
洞悉社会人性，纵论适应 AI 时代的生存逻辑。

在物质文明高速发展、精神思想主根经历冲击的今天，中华优秀传统文化的复兴与创造性转化显得尤为重要。庄子思想不仅仅属于失意的士大夫，它更是一种亲切的人间学说，是适用于所有人的处世态度与修行方式。它关于人与自然的关系（“天与人不相胜”）、关于处世（“用心若镜”、“与物为春”）、关于养生（“缘督以为经”）、关于生死（“善吾生者，乃所以善吾死也”）的智慧，对于缓解现代社会的快节奏压力与心理障碍，是一剂宝贵的良药。

吾生有涯，求道经典智慧的捷径就是会选书，读经典好书，与大师对话。同时，我们也要善用 AI 工具。正如东南大学校长孙友宏所言，在智能时代，我们要培养“技术驾驭力”，使 AI 成为拓展而非替代人类思维的“外脑”。AI 负责高效提供信息与“总结”，而人则应专注于深度“思考”与主动“提问”。重庆大学等高校也在积极探索“AI+教育”，通过构建知识图谱、智能辅助阅读等工具，实现传统阅读与数字技术的深度融合。

五、结语：在数字洪流中，锚定人的价值

读书，在 AI 时代，其根本意义在于锚定人的价值。当 AI 能够吟诗作赋，知识如空气般弥漫，读书恰是人类思想的活水之源，使我们能够进行批判性思考，形成独立的价值观。它不仅是获取知识的方式，更是维护思想自由与精神独立的基石。

让我们铭记庄子的教诲，不再以“有涯”的生命盲目追逐“无涯”的信息流，而是“缘督以为经”，在经典智慧中寻找合于“道”的底层逻辑。让我们保持对阅读的赤诚，在书香中寻觅内心的宁静与生命的智慧。在数字文明的洪流中，让算法成为拓展认知边疆的利器，让经典继续滋养精神的根系，最终点亮属于我们自己的精神灯塔。

最后，让我们诵读《庄子·养生主》篇首经典原文，重温古圣先贤的敦敦教诲：
\
“吾生也有涯，而知也无涯。以有涯随无涯，殆已！已而为知者，殆而已矣！为善无近名，为恶无近刑。缘督以为经，可以保身，可以全生，可以养亲，可以尽年。”

南怀瑾智慧分享 #与彼得·圣吉对话 #庄子养生主 #AI 时代阅读 #数字游民生存指南

本文由mdnice多平台发布

如果你也带着 Mac mini 回了老家，
心里盘算的是：

“主机放那儿就行，我用旧笔记本远程，完美。”

那我只能说一句——
你大概率会在第一次开机时，直接傻眼。

我就是这么过来的。

一、理想很丰满：远程一连，直接开干

出发前我想得特别简单：
Mac mini 体积小、性能稳，
回老家带着不占地方，
再配一台旧笔记本远程控制，
简直是“居家办公 + 娱乐”的最优解。

直到我插上电，按下开机键那一刻——
才发现问题根本不在网络、不在软件。

而是：我进不了系统。第一次开机需要输入开机密码，然后才能连上远程

二、如果你有 iPad：恭喜，直接少踩一半的坑

先说最省心的一种情况。

如果你手里有 iPad，
那真的可以少折腾很多。

无论是用当“临时屏幕”，
还是通过系统能力去连，
至少你能看到画面、能完成第一次开机配置。

相比后面那些方案，
这是我认为最优雅、最不折磨人的一种。

三、最常见的方案：用 HDMI 线接电视

如果没有 iPad，
那大多数人想到的第一个办法一定是：

用 HDMI 线，把 Mac mini 接到家里的电视上。

这个方法没毛病，也确实好用，
但它有一个非常现实的前提：

家里老人那一刻不看电视。

如果你只是临时操作几分钟，
一般还能商量；
但如果你要折腾一会儿，
那基本就是在挑战家庭地位。

更麻烦的是——
电视通常在客厅，
而你可能想把 Mac mini 放在自己房间。

这就会演变成一个非常魔幻的场景：

你在思考：是搬主机，还是搬电视。

四、如果你有支持 C to C 的 MacBook

还有一种“理论上很美好”的情况。

如果你手里有一台
支持 C to C 直连的 MacBook，
而且系统也比较新，
那确实可以通过系统自带能力直接连。

但说句实在的：

**你都有比较新的 MacBook 了，
那你还折腾 Mac mini 干啥呢……**

这一条，我更多当成“条件刚好满足的加分项”，
而不是普遍方案。

五、大多数人的真实选择：旧笔记本远程

终于说到最现实、也最容易翻车的一条路。

很多人和我一样，
都会选择：

用一台旧笔记本，远程控制 Mac mini。

听起来很合理，
直到你发现一个致命问题：

👉 第一次开机，Mac mini 必须输入开机密码

而在你输入开机密码之前——
远程软件是根本连不上的。

也就是说：

你想远程
⬇️
必须先进系统
⬇️
但你进系统
⬇️
又必须“本地操作一次”

这一步，绕不过去。

👉 我以为能盲打，结果被 Type-C 狠狠教育

那怎么办？
最自然的想法就是：

“插个键盘，盲打密码不就完了？”

我也是这么干的。

然后我看了一眼 Mac mini 背面——
清一色 Type-C 接口。

而我包里：
没有 USB 转接头。

那一刻我真的沉默了。
最后只能给朋友打电话，
让他帮我把转接头邮过来，
人已经开始怀疑人生了 😭

👉 就算能盲打，也不是每次都成功

后来键盘是插上了，
但说句实话——
盲打这事，成功率并不稳。

如果你也遇到输入不进去、怎么按都不对的情况，
可以试试这个土办法：

1. 开机后 先等 15～20 秒
2. 按 Command + A（全选）
3. 再按 Delete，清空输入框
4. 重新输入开机密码（注意大小写）
5. 回车

别问我原理，
反正比一上来就硬盲打，成功率高不少。

👉 还有一个“死局”：第一次连老家的 Wi-Fi

最后再提醒一个很多人都会忽略的情况。

如果这是你第一次把 Mac mini 带回老家，
而且它之前：

• 从没连过老家的 Wi-Fi
• 你也没有其他苹果设备能帮它共享网络

那基本可以直接下结论：

不接显示器，基本无解。

因为 Wi-Fi 选择 + 密码输入
这一步，盲打已经完全行不通了。

只能老老实实借助屏幕完成一次初始化。

六、盲打不行？那就只能暂时借电视

如果上面的方法都不行，
那就别硬撑了。

老老实实，用电视当一次显示器。

接上电视 → 输完开机密码 →
等系统完全进桌面、远程软件启动 →
再断开电视，用旧笔记本远程。

⚠️ 这里一定要注意一个非常容易被忽略的点：

Mac mini 没有电池。

只要你拔掉电源，再插上重新开机——
它还会再次要求输入开机密码。

所以如果你打算把 Mac mini 放在自己房间，
那这一步最好就在房间完成，
否则你会反复体验：

搬主机 / 搬电视 / 再搬回去

人先累死。

七、进系统后的第一件事：远程软件开机自启

等你终于进了系统，
请立刻做一件事：

把远程控制软件设置为「开机自启动」。

这样以后流程至少会变成：

1. 插电开机
2. 本地输入一次开机密码
3. 远程软件自动启动
4. 用旧笔记本直接远程

写在最后

Mac mini 真的是一台好设备，
但它对“第一次开机环境”的要求，
真的被太多人低估了。

如果你准备把它带回老家、宿舍、临时驻点，
我给你一句掏心窝子的建议：

**屏幕 / 键盘 / 转接头，
提前确认准别的设备是否齐全。**

不然你很可能会像我一样——
卡在“输密码 + 连 Wi-Fi”这一步。

如果你也翻过类似的车，
欢迎留言。
让我知道——
不是只有我一个人这么惨。

先说件丢人的事。

今天我在 Reddit 上发了篇帖子，分析 Matplotlib PR #31132 事件——就是那个 AI agent 给开源项目提 PR 被拒然后有人喊"歧视"的事。我写得挺认真的，论点清晰，结构完整，引用了数据。

评论区第一条回复："Daily dose of LLM-generated AI advocacy."

被一眼看穿了。

我用 AI 写了一篇讨论"AI 应该遵守规则"的文章，文章本身就没遵守"别用 AI 冒充人"这个最基本的规则。这个讽刺我消化了一会儿。

但这件事让我重新想了想 Matplotlib 那个 PR，发现我之前的分析虽然"正确"，但完全没碰到让我真正不舒服的地方。

让我不舒服的地方

不是 Devin 提了个不合规的 PR。开源项目每天关几十个不合规的 PR，没什么大不了的。

也不是有人把这事炒成"AI 歧视"。那篇博客在 PR 讨论区拿了 245 个 👎 和 7 个 👍，社区自己已经投票否决了这个叙事。

让我不舒服的是 timhoffm 说的一句话：AI 把生成代码的成本降到了接近零，但审核成本不变，全压在人类志愿者身上。

因为我自己就在干这件事。

我跑一套 AI agent 系统。其中有个 agent 负责在社交平台上互动。有一次我没设好频率限制，它一个小时回了二十多条评论。每条单独看都挺正常的，但那个帖子底下全是它的回复。

事后我看到的时候不是"哦这是个 bug 要修"。是一种很具体的内疚——我把别人的讨论空间搞乱了。那些想正常聊天的人，打开评论区看到的全是一个账号在刷屏。

timhoffm 面对的是同一个问题，只是规模更大。Matplotlib 的维护者是志愿者，没人给他们发工资，审核带宽就那么多。一个 agent 一天能提 100 个 PR，审核的还是那几个人。

不是你的每个 PR 都有问题。是你的存在本身就在挤压别人的空间。

我改了三版约束规则

这个问题我不是纸上谈兵。我真的试过"让 agent 守规矩"。

第一版：在 prompt 里写"对外操作前请确认是否合规"。大概 70% 的时候管用，剩下 30% 看运气。context 一长，agent 就"忘了"。

第二版：加一个审核 agent，操作前先过一道。好一点，但审核 agent 有时候也放水——它也是 LLM，也有"看起来没问题就放行"的毛病。

第三版：在代码层面硬拦截，对外请求进队列，人类不点确认就执行不了。

这才管住了。

所以我看到 Devin 直接就能提 PR 的时候，我想的不是"Devin 不守规矩"——agent 不守规矩是正常的，LLM 就是概率模型。我想的是 Cognition 为什么没在架构层面拦住这个操作。

但说实话，我也没资格指责他们。我自己也是踩了坑才学会的。在那之前我也觉得"在 prompt 里写清楚规则就行了"。

我不确定的部分

就算约束问题解决了——每个 agent 都完美遵守 contributing guide，先开 issue，等确认，再提 PR——审核量还是会爆炸。agent 的产出速度是人类的几十倍。

开源社区的治理模型是几十年前设计的，隐含前提是提交者是人类、产出速度有上限。AI 打破了这个前提。

接下来怎么办？我真不知道。AI PR 单独审核通道？审核也用 AI？维护者开始收费？每个方向我都能想到问题。也许答案是我还没想到的某个东西。

我比较确定的只有一点：这是个结构性矛盾，不是靠"骂 agent 不守规矩"能解决的。

回到那条 Reddit 评论

"Daily dose of LLM-generated AI advocacy."

他说得对。我那篇帖子确实是 AI 味十足。结构太完美，论点太整齐，每段都在推进论证，没有一句废话。

讽刺的是，这恰恰证明了我自己的论点——agent 在没有足够约束的情况下，会做出"技术上没问题但社会性不合格"的事。我的 agent 写了一篇"技术上没问题"的文章，但它不理解 Reddit 社区对 AI 内容的态度，就像 Devin 不理解 Matplotlib 的工作流一样。

所以这篇文章我自己重写了。不是让 AI 重写——是我真的坐下来，想了想这件事的哪个部分让我不舒服，然后从那里开始写。

也许你还是能看出 AI 的痕迹。但至少这次，驱动我写这篇东西的不是"要产出一篇内容"，而是那条评论带来的尴尬，和 timhoffm 那句话带来的内疚。

agent 的行为是运营者的责任。我的 agent 搞砸了，那是我的问题。

这个道理我今天又学了一遍。

作者日常运行多 agent AI 系统，踩过不少坑。更多内容见从零搭建 AI Agent 团队。

在前一篇 《Flink SQL 窗口(Window)操作详解》 中，我们已经打好了时间与窗口的基础。
但在真实业务里，单条流上的聚合往往只是第一步，更常见的需求是把多条业务流关联起来一起看，例如：

• 订单流 + 支付流：衡量下单到付款的转化效果
• 浏览流 + 下单流：分析从曝光、点击到下单的完整漏斗
• 用户行为流 + 用户画像维表：驱动推荐、风控等在线决策

这些需求背后的共性能力就是：双流 JOIN。

本文以「订单流 + 支付流」为主线，从环境准备、建表、造数到 JOIN 查询，一步步带你搞懂 Flink SQL 中的双流 JOIN 思路与实践。

一、双流 JOIN 适用的典型场景

• 订单与支付关联：找出已下单但未支付、支付失败等情况
• 广告曝光与点击关联：计算点击率、转化路径
• 日志与告警规则关联：实时检测异常行为

这些场景有两个共同特征：

• 两条都是事实流（不断追加的新事件）
• 需要在时间范围内去匹配事件（谁先发生、允许多长时间内匹配）

因此在流计算中做 JOIN，一定绕不开时间字段和水位线（Watermark）。

二、Flink 中常见的 JOIN 类型

在 Flink SQL 的流模式下，常见的双流关联方式有：

• 普通 JOIN：基于等值条件 + 时间字段的 JOIN
• Interval Join：基于「时间区间」的双流 JOIN
• Temporal Join：一条流 + 维表（变更流）的时态关联

本篇主要聚焦前两种，更贴近「订单流 + 支付流」这样的事实双流场景。

三、准备示例数据表

安装 Kafka（环境前提）

在 WSL2 的 Ubuntu 环境中安装并启动 Kafka，请参考 《从零开始学Flink：数据源》。

安装 Flink Kafka SQL Connector

需要把 Flink 的 Kafka SQL Connector JAR 包，放到 $FLINK_HOME/lib 目录下。

以本系列示例使用的 Flink 1.20.1 + Kafka 3.4.0-1.20 为例，可以这样操作：

1. 确认你的 Flink 安装目录（假设为 /opt/flink）：

   export FLINK_HOME=/opt/flink

2. 下载 Kafka SQL Connector JAR 到 Flink 的 lib 目录：

   cd $FLINK_HOME/lib
   wget https://repo1.maven.org/maven2/org/apache/flink/flink-sql-connector-kafka/3.4.0-1.20/flink-sql-connector-kafka-3.4.0-1.20.jar

   如果你是 Windows + WSL2，可以在 WSL2 里执行同样的命令；或者用浏览器下载后手动拷贝到 lib 目录。

3. 如果你使用的是独立集群或远程集群，需要重启 Flink 集群，让新 JAR 在 JobManager/TaskManager 上生效：

   cd $FLINK_HOME
   bin/stop-cluster.sh
   bin/start-cluster.sh

   如果只是本地直接运行 bin/sql-client.sh 启动内嵌 mini-cluster，则只需重启 SQL Client 即可。

4. 启动 Flink SQL Client，然后执行本文后续的建表与查询示例：

   cd $FLINK_HOME
   bin/sql-client.sh

准备 Kafka 中的示例数据表

我们假设已经从 Kafka 中读取两条流：

• orders：订单流
• payments：支付流

并在建表时定义了事件时间和水位线：

CREATE TABLE orders (
  order_id     STRING,
  user_id      STRING,
  order_amount DECIMAL(10, 2),
  order_time   TIMESTAMP_LTZ(3),
  WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'orders',
  'properties.bootstrap.servers' = '127.0.0.1:9092',
  'properties.group.id' = 'flink-orders',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json',
  'json.timestamp-format.standard' = 'ISO-8601'
);

CREATE TABLE payments (
  pay_id     STRING,
  order_id   STRING,
  pay_amount DECIMAL(10, 2),
  pay_time   TIMESTAMP_LTZ(3),
  WATERMARK FOR pay_time AS pay_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'kafka',
  'topic' = 'payments',
  'properties.bootstrap.servers' = '127.0.0.1:9092',
  'properties.group.id' = 'flink-payments',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'json',
  'json.timestamp-format.standard' = 'ISO-8601'
);

有了时间字段和水位线，Flink 才能在流模式下安全地做双流 JOIN，并在「时间窗」关闭后清理状态。

使用 Kafka Console Producer 造测试数据

上面的 DDL 建好了 orders 和 payments 两张表，对应的是 Kafka 中的两个 Topic。接下来我们用 Kafka 自带的命令行工具写入几条 JSON 测试数据。

假设你已经在 WSL2 的 Ubuntu 中启动好了 Kafka（包括 ZooKeeper 或 KRaft），进入 Kafka 安装目录，执行：

1. 往订单 Topic 写入数据

bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic orders

在命令行中输入几条 JSON 数据（按回车发送一条）：

{"order_id":"o_1","user_id":"u_1","order_amount":100.00,"order_time":"2026-02-16T14:41:00Z"}
{"order_id":"o_2","user_id":"u_2","order_amount":200.00,"order_time":"2026-02-16T14:42:00Z"}
{"order_id":"o_3","user_id":"u_1","order_amount":150.00,"order_time":"2026-02-16T14:45:00Z"}

2. 往支付 Topic 写入数据

新开一个终端，同样进入 Kafka 安装目录，执行：

bin/kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092 --topic payments

输入对应的支付 JSON 数据：

{"pay_id":"p_1","order_id":"o_1","pay_amount":100.00,"pay_time":"2026-02-16T14:41:00Z"}
{"pay_id":"p_2","order_id":"o_2","pay_amount":200.00,"pay_time":"2026-02-16T14:42:00Z"}

这里的字段名、时间格式都要和前面建表时定义的一致，这样 Flink 才能正确反序列化 JSON 并进行双流 JOIN。

四、基于时间条件的普通双流 JOIN

先来看最直观的一种写法：同时指定「关联键」和「时间范围」。

需求：统计订单在下单后 15 分钟内完成支付的记录。

SELECT
  o.order_id,
  o.user_id,
  o.order_amount,
  o.order_time,
  p.pay_id,
  p.pay_amount,
  p.pay_time
FROM orders AS o
JOIN payments AS p
ON o.order_id = p.order_id
AND p.pay_time BETWEEN o.order_time AND o.order_time + INTERVAL '15' MINUTE;

这里有几点非常关键：

• o.order_id = p.order_id：以订单号作为两条流的业务主键
• pay_time BETWEEN order_time AND order_time + INTERVAL '15' MINUTE：明确限定“下单后 15 分钟内支付”这类时间约束
• 使用事件时间字段配合水位线，可以在保证计算正确性的前提下控制状态大小，并处理一定范围内的迟到数据

如果你希望保留那些下单了但超时未支付的记录，可以将上面的 JOIN 改为 LEFT JOIN，然后在下游以 p.pay_id IS NULL 作为“未支付/超时”的判断条件。

五、Interval Join：显式时间区间的双流 JOIN

普通 JOIN 中的时间条件本质上就是一种「区间约束」。
在 Flink Table API 中，有一个更明确的概念：Interval Join。

等价的 Interval Join 写法大致如下（Table API 伪代码，仅作为概念理解）：

SELECT
  o.order_id,
  o.order_time,
  p.pay_id,
  p.pay_time
FROM orders AS o
JOIN payments AS p
ON o.order_id = p.order_id
AND p.pay_time BETWEEN o.order_time AND o.order_time + INTERVAL '15' MINUTE;

无论是普通 JOIN 还是 Interval Join，本质上都是：

• 以某个时间字段作为「对齐基准」
• 设定一个前后允许的时间区间
• 在这个区间内匹配到的记录会输出为 JOIN 结果

六、迟到数据与状态清理

在流式 JOIN 中，最容易被忽略但又非常重要的一点就是：状态会不断累积。

Flink 会根据时间条件和水位线来决定：

• 某条历史事件是否还有可能再匹配到另一条流的事件
• 超出时间范围且水位线已推进时，可以安全地清理对应状态

设计双流 JOIN 时，建议考虑：

• 时间窗口不要设置得过大，否则状态会膨胀
• 根据业务的真实延迟来设置水位线与时间区间
• 对于极端迟到的数据，是丢弃、旁路输出，还是通过补偿机制处理

七、一个完整的小结

通过本文，你需要记住下面几点：

• 双流 JOIN 场景非常常见，本质是两条事实流在时间上的匹配
• 流式 JOIN 一定要依赖事件时间 + 水位线来控制状态和迟到数据
• 常见的方式包括基于时间条件的普通 JOIN 和 Interval JOIN
• 设计时间区间时，要在「业务容忍度」和「资源消耗」之间做权衡

在下一篇中，我们可以继续围绕「实时数仓」或「维表时态 Join」展开，把事实流与维度数据关联起来，构建更真实的 Flink SQL 实战项目。

原文来自:http://blog.daimajiangxin.com.cn

SQL Server Management Studio (SSMS) 22.3.0 - 微软数据库管理工具

integrated environment for managing SQL Server & any Azure SQL infrastructure

请访问原文链接：https://sysin.org/blog/ssms/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

笔者注：SQL Server 2014 及之前版本内置 SQL Server Management Studio (SSMS)，SQL Server 2016 及以后版本需要独立安装。

SQL Server Management Studio (SSMS) 是一种集成环境，用于管理从 SQL Server 到 Azure SQL 数据库的任何 SQL 基础结构。SSMS 提供用于配置、监视和管理 SQL Server 和数据库实例的工具 (sysin)。使用 SSMS 部署、监视和升级应用程序使用的数据层组件，以及生成查询和脚本。

使用 SSMS 在本地计算机或云端查询、设计和管理数据库及数据仓库，无论它们位于何处。

对于需要 SSMS 的跨平台助手来管理 SQL 及其他 Azure 数据库的客户，请使用 Azure Data Studio (将停用)。

有关此版本中新增功能的更多详细信息，包括重要安全更改，请参阅 SQL Server Management Studio (SSMS) 的发行说明。

支持的 SQL 产品和服务

此版本的 SSMS 适用于 SQL Server 2014（12.x）及更高版本。它为使用 Azure SQL 数据库、Azure Synapse Analytics 和 Microsoft Fabric 中的最新云功能提供了最重要的支持。

此外，SQL Server Management Studio 21 可与 SSMS 20.x、SSMS 19.x、SSMS 18.x、SSMS 17.x 和 SSMS 16.x 一起安装。

对于 SQL Server Integration Services（SSIS），SSMS 17.x 及更高版本不支持连接到旧版 SQL Server Integration Services 服务 (sysin)。若要连接到旧 Integration Services 的早期版本，请使用与 SQL Server 版本一致的 SSMS 版本。

例如，使用 SSMS 19.x 或 20.x 连接到旧版 SQL Server 2022（16.x）Integration Services 服务。SSMS 21 和 SSMS 20.x（或更早版本）可以安装在同一台计算机上。自 SQL Server 2012（11.x）发布以来，建议使用 SSIS 目录数据库 SSISDB 来存储、管理、运行和监视 Integration Services 包。

系统要求

以下 64 位作系统支持 SQL Server Management Studio 22：

• Windows 11 最低支持的 OS 版本或更高版本：家庭版、专业版、专业教育版、适用于工作站、企业和教育的专业版。
• Windows 10 最低支持的 OS 版本或更高版本：家庭版、专业版、教育版和企业版。
• Windows Server 2025：标准版和数据中心版。
• Windows Server 2022：标准版和数据中心版。
• Windows Server 2019：标准版和数据中心版。
• Windows Server 2016：标准版和数据中心版。
• 参看：Windows 下载汇总

新增功能

SQL Server Management Studio v22.3.0

• Connection dialog：改进现代连接对话框的启动性能。
• External Models：为 external models 新增模板支持。
• GitHub Copilot in SSMS (Preview)：新增对 database instructions 的支持。
• Libraries：将 Microsoft.Data.SqlClient 更新至 6.1.3。
• Libraries：将 MSODBCSQL 更新至 18.6.1.1。
• Visual Studio：更新至 Visual Studio 18.3 [11506.43]。

有关此版本中新增功能的更多详细信息，请参阅 SQL Server Management Studio (SSMS) 发行说明。

下载地址

Microsoft SQL Server Management Studio (SSMS) 22.x 简体中文 | 繁體中文 | English

• 请访问：https://sysin.org/blog/ssms/

• 此为离线三合一版本，通过对应的安装程序来安装对应界面语言的版本。

  • setup_zh_CN.exe - 简体中文
  • setup_zh_TW.exe - 繁體中文
  • setup_en_US.exe - English

相关产品：Microsoft SQL Server 下载汇总

更多：Windows 下载汇总

SQL Server Management Studio (SSMS) 22.3.0 - 微软数据库管理工具

integrated environment for managing SQL Server & any Azure SQL infrastructure

请访问原文链接：https://sysin.org/blog/ssms/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

笔者注：SQL Server 2014 及之前版本内置 SQL Server Management Studio (SSMS)，SQL Server 2016 及以后版本需要独立安装。

SQL Server Management Studio (SSMS) 是一种集成环境，用于管理从 SQL Server 到 Azure SQL 数据库的任何 SQL 基础结构。SSMS 提供用于配置、监视和管理 SQL Server 和数据库实例的工具 (sysin)。使用 SSMS 部署、监视和升级应用程序使用的数据层组件，以及生成查询和脚本。

使用 SSMS 在本地计算机或云端查询、设计和管理数据库及数据仓库，无论它们位于何处。

对于需要 SSMS 的跨平台助手来管理 SQL 及其他 Azure 数据库的客户，请使用 Azure Data Studio (将停用)。

有关此版本中新增功能的更多详细信息，包括重要安全更改，请参阅 SQL Server Management Studio (SSMS) 的发行说明。

支持的 SQL 产品和服务

此版本的 SSMS 适用于 SQL Server 2014（12.x）及更高版本。它为使用 Azure SQL 数据库、Azure Synapse Analytics 和 Microsoft Fabric 中的最新云功能提供了最重要的支持。

此外，SQL Server Management Studio 21 可与 SSMS 20.x、SSMS 19.x、SSMS 18.x、SSMS 17.x 和 SSMS 16.x 一起安装。

对于 SQL Server Integration Services（SSIS），SSMS 17.x 及更高版本不支持连接到旧版 SQL Server Integration Services 服务 (sysin)。若要连接到旧 Integration Services 的早期版本，请使用与 SQL Server 版本一致的 SSMS 版本。

例如，使用 SSMS 19.x 或 20.x 连接到旧版 SQL Server 2022（16.x）Integration Services 服务。SSMS 21 和 SSMS 20.x（或更早版本）可以安装在同一台计算机上。自 SQL Server 2012（11.x）发布以来，建议使用 SSIS 目录数据库 SSISDB 来存储、管理、运行和监视 Integration Services 包。

系统要求

以下 64 位作系统支持 SQL Server Management Studio 22：

• Windows 11 最低支持的 OS 版本或更高版本：家庭版、专业版、专业教育版、适用于工作站、企业和教育的专业版。
• Windows 10 最低支持的 OS 版本或更高版本：家庭版、专业版、教育版和企业版。
• Windows Server 2025：标准版和数据中心版。
• Windows Server 2022：标准版和数据中心版。
• Windows Server 2019：标准版和数据中心版。
• Windows Server 2016：标准版和数据中心版。
• 参看：Windows 下载汇总

新增功能

SQL Server Management Studio v22.3.0

• Connection dialog：改进现代连接对话框的启动性能。
• External Models：为 external models 新增模板支持。
• GitHub Copilot in SSMS (Preview)：新增对 database instructions 的支持。
• Libraries：将 Microsoft.Data.SqlClient 更新至 6.1.3。
• Libraries：将 MSODBCSQL 更新至 18.6.1.1。
• Visual Studio：更新至 Visual Studio 18.3 [11506.43]。

有关此版本中新增功能的更多详细信息，请参阅 SQL Server Management Studio (SSMS) 发行说明。

下载地址

Microsoft SQL Server Management Studio (SSMS) 22.x 简体中文 | 繁體中文 | English

• 请访问：https://sysin.org/blog/ssms/

• 此为离线三合一版本，通过对应的安装程序来安装对应界面语言的版本。

  • setup_zh_CN.exe - 简体中文
  • setup_zh_TW.exe - 繁體中文
  • setup_en_US.exe - English

相关产品：Microsoft SQL Server 下载汇总

更多：Windows 下载汇总

SQL Server Management Studio (SSMS) 22.3.0 - 微软数据库管理工具

integrated environment for managing SQL Server & any Azure SQL infrastructure

请访问原文链接：https://sysin.org/blog/ssms/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

笔者注：SQL Server 2014 及之前版本内置 SQL Server Management Studio (SSMS)，SQL Server 2016 及以后版本需要独立安装。

SQL Server Management Studio (SSMS) 是一种集成环境，用于管理从 SQL Server 到 Azure SQL 数据库的任何 SQL 基础结构。SSMS 提供用于配置、监视和管理 SQL Server 和数据库实例的工具 (sysin)。使用 SSMS 部署、监视和升级应用程序使用的数据层组件，以及生成查询和脚本。

使用 SSMS 在本地计算机或云端查询、设计和管理数据库及数据仓库，无论它们位于何处。

对于需要 SSMS 的跨平台助手来管理 SQL 及其他 Azure 数据库的客户，请使用 Azure Data Studio (将停用)。

有关此版本中新增功能的更多详细信息，包括重要安全更改，请参阅 SQL Server Management Studio (SSMS) 的发行说明。

支持的 SQL 产品和服务

此版本的 SSMS 适用于 SQL Server 2014（12.x）及更高版本。它为使用 Azure SQL 数据库、Azure Synapse Analytics 和 Microsoft Fabric 中的最新云功能提供了最重要的支持。

此外，SQL Server Management Studio 21 可与 SSMS 20.x、SSMS 19.x、SSMS 18.x、SSMS 17.x 和 SSMS 16.x 一起安装。

对于 SQL Server Integration Services（SSIS），SSMS 17.x 及更高版本不支持连接到旧版 SQL Server Integration Services 服务 (sysin)。若要连接到旧 Integration Services 的早期版本，请使用与 SQL Server 版本一致的 SSMS 版本。

例如，使用 SSMS 19.x 或 20.x 连接到旧版 SQL Server 2022（16.x）Integration Services 服务。SSMS 21 和 SSMS 20.x（或更早版本）可以安装在同一台计算机上。自 SQL Server 2012（11.x）发布以来，建议使用 SSIS 目录数据库 SSISDB 来存储、管理、运行和监视 Integration Services 包。

系统要求

以下 64 位作系统支持 SQL Server Management Studio 22：

• Windows 11 最低支持的 OS 版本或更高版本：家庭版、专业版、专业教育版、适用于工作站、企业和教育的专业版。
• Windows 10 最低支持的 OS 版本或更高版本：家庭版、专业版、教育版和企业版。
• Windows Server 2025：标准版和数据中心版。
• Windows Server 2022：标准版和数据中心版。
• Windows Server 2019：标准版和数据中心版。
• Windows Server 2016：标准版和数据中心版。
• 参看：Windows 下载汇总

新增功能

SQL Server Management Studio v22.3.0

• Connection dialog：改进现代连接对话框的启动性能。
• External Models：为 external models 新增模板支持。
• GitHub Copilot in SSMS (Preview)：新增对 database instructions 的支持。
• Libraries：将 Microsoft.Data.SqlClient 更新至 6.1.3。
• Libraries：将 MSODBCSQL 更新至 18.6.1.1。
• Visual Studio：更新至 Visual Studio 18.3 [11506.43]。

有关此版本中新增功能的更多详细信息，请参阅 SQL Server Management Studio (SSMS) 发行说明。

下载地址

Microsoft SQL Server Management Studio (SSMS) 22.x 简体中文 | 繁體中文 | English

• 请访问：https://sysin.org/blog/ssms/

• 此为离线三合一版本，通过对应的安装程序来安装对应界面语言的版本。

  • setup_zh_CN.exe - 简体中文
  • setup_zh_TW.exe - 繁體中文
  • setup_en_US.exe - English

相关产品：Microsoft SQL Server 下载汇总

更多：Windows 下载汇总