前言

之前我们公司有个项目组搞了个 AI 大模型推荐功能，眼看就要上架了，结果产品突然找过来说：

“那个 AI 推荐的模块先别放了，先隐藏吧，怕上架审核出问题。”

为了赶时间，技术那边就临时加了个判断，把入口在前端藏起来，赶紧发了个版本，算是暂时搞定。

结果没过几天，又说要发版本。我一问咋了？技术一脸生无可恋：

“产品又说 AI 那个功能现在可以公测了，要放出来了。”

好吧，那就再发一次......

然后没几天，产品又说要隐藏掉，说模型结果不稳定要临时下线。

“先别公测了，发现有问题，先关掉再说。”

听说那天技术已经气到跟产品去厕所单挑了……

我当时的内心 OS 是：这也太反复了吧？到底是想上还是不想上？

这种“上线前隐藏，上线后又展示，再隐藏”的操作，不是一次两次了。

所以我们当时就想了：

既然这些需求只是改个显示开关、调个默认值，为啥不干脆给他们一个“自助按钮”？别每次都让我们改代码发版本，产品自己调着玩不好吗？

于是我们开始在后台做一套简单的业务配置中心，目标就是：

• 产品、运营可以自己配置功能开关、文案、参数，不用找开发


• 配置修改能实时生效，不用再发版本


• 支持输入类型、下拉选项、开关按钮、范围数值，想怎么配就怎么配

这不是为了什么“大中台”，就是想解决那些一天三改、两小时一调的需求，把这些琐碎从开发日常里剥离出去。

这些配置，说改就改，好烦人

其实像上面的这个事情 在我们日常开发中太常见了。

举几个我亲身经历的例子就知道为啥我们非得搞个配置中心：

• 登录要不要加图形验证码？
  
  一开始为了用户体验不加，结果突然哪天注册量暴涨，一查是黑产在刷。产品急了：“赶紧加验证码！”
  
  技术临时改、测试、上线……黑产已经溜了，下次再刷又得重来一遍。为啥不做个开关自己控制？


• 推荐功能的参数一天一个样
  
  有一版产品说“默认推荐 5 个兴趣标签”，隔两天又改成 3 个，再过几天又要回 4 个，说“现在运营数据反馈不一样了”。
  
  我寻思你都能自己看数据了，那你为啥不能自己改参数？


• 短信通道经常切换
  
  阿里、腾讯、网易云信……一个月能换仨。原因也很实在，要么是价格问题，要么是运营说“昨天验证码收不到”。
  
  每次换通道都得技术去代码里改 templateId、signName，我真想把接口都写成配置项，让你们爱换谁换谁。


• 活动逻辑说改就改
  
  运营：“这个弹窗逻辑改一下，注册就弹。”
  
  上了之后运营又说：“太打扰用户了，还是调成登录 3 天之后再弹。”
  
  这不就一行逻辑的事，但每次都要发版真心烦。

像这些情况，改的不是业务逻辑，就是个值、个条件、个开关。但只要没抽出来配置，就只能靠技术手动改代码，一点都不优雅，还特别浪费时间。

所以后来我们就想，还是干脆统一搞个配置后台吧，把这些“天天改、随时调”的破事都收进去，让配置能看得见、改得了、控得住，技术这边也能轻松点。

之前我们配置到底怎么管的？说实话，说出来都不太好意思：

• 有的直接写死在代码里，变量名都不带解释的，谁写的谁才知道啥意思；


• 稍微规范一点的，会统一搞个 config 文件，但也只是“技术自己看得懂”的那种；


• 更混乱的是，有的配置写在 yml，有的塞在数据库，还有的干脆“哪里用到就哪里写”，找都找不到；


• 最离谱的是：业务运营类的配置和技术底层的配置，全堆一起，切短信通道这种运营配置放在 core-service 的 application.yml 里，看得人脑壳疼。

等到要改配置的时候，产品和运营根本不知道去哪改，开发也得翻半天才能定位是哪段逻辑控制的，甚至还会不小心把技术底层配置给动了……这种时候就明白了，没有一套清晰、隔离、可视化的配置系统，迟早乱套。

配置也要讲规矩，不能啥都往后台扔

当然，配置中心也不是说所有配置都往后台一丢就完事了。

我们踩过这个坑。

最早的时候我们也想偷懒，把所有配置（技术的、业务的、运营的）都塞在统一的配置文件里，比如 config.php 或 application.yml 里，统一读就完了，听起来挺美的。

但实际用下来，真的是——乱！成！一！锅！粥！

一方面，业务/运营配的东西，是给人看的，得讲人话。

比如：

• 推荐位默认展示几个内容？


• 某个功能在特定版本下是否开启？


• 发奖的触发条件设置为几天内登录？

这些运营同学自己都能理解，也希望自己能控制，那就该做成后台可配置、能预览、能实时生效的。

但另一方面，有些配置就不能乱动，或者干脆不应该给后台看到：

• MQ 消费 topic 名


• 数据库连接池配置


• 是否启用 debug 模式


• 线上某些敏感接口的限频值

如果我们把这些放给业务方看，他们可能都不知道是干嘛的，不小心点了一下，系统都能给整崩了……

所以后来我们就统一了一套大致的“配置分级规则”：

有些配置是纯技术底层的，比如 MQ 的 topic 名、接口限流的阈值、日志采样比例、数据库连接池大小……

这些属于“动一下系统都可能出事”的类型，不给任何后台入口，完全由技术团队内部维护，最好写死或写进 yml 里。

然后是那种纯运营向的配置，比如功能开关、首页推荐展示几个卡片、某段文案内容、活动弹窗的显示时间等等。

这些配置逻辑上不会出啥大问题，但会被运营天天来回调整，必须放后台让他们自己搞，不然技术早晚被烦死。

还有一种是产品经常会动的业务规则类配置，比如：

• 某个功能灰度给哪些版本开放；


• 某个打点逻辑的间隔时间怎么设；


• 是否对新用户显示某个引导。

这些其实也不属于“技术配置”，而是产品为了做 A/B 测试、做用户分群、验证效果临时改的，技术只负责“支持能力”，真正的“值”还是应该交给产品自己配。

我们就按照这个思路，把技术底层的隐藏掉，只暴露运营类和业务类配置给后台，谁负责谁管理。改错了好歹还能找到人。

这样一来，配置中心的边界清晰了，技术也不用再被无限兜底，系统也能跑得更稳定，团队分工也更顺。

配置中心该长啥样？我们定了几个目标

前面说了那么多需求、痛点、吵架场面（划掉），那我们到底想要一个什么样的配置中心呢？

说白了，我们的目标很简单：

能分清模块，分清人，分清配置类型，能改能看能预览，最好技术都不用管。

那我们是怎么拆功能的呢？最初的设计版本是这样的：

1. 配置要能分模块

不能全堆一起。

我们一个项目，最少有这些模块：系统相关、用户系统、运营活动、AI 任务、通知推送、发奖逻辑……每个模块都有自己的配置。

所以我们一开始就支持“按模块分组”，一个模块里挂多个配置项，清清楚楚谁负责啥，谁爱改啥自己管。

2. 每个配置项要有“类型”

这个最开始我们踩过坑。

最初只做了输入框，结果运营输入一堆错格式的东西，改出 bug。后来我们就定了：所有配置项必须类型化，根据使用场景来限定可选值/格式。

目前我们支持的类型大概是这几种：

• 输入框：最普通的文本输入，比如标题、url、提示语。


• 范围值：像“10~100”这种，就搞个最小|最大格式，自动校验。


• 下拉框：适合选模板、选模型、选渠道。


• 单选框：跟下拉差不多，看场景展示方式不同。


• 开关：很直观，是否开启、是否显示，一眼看懂。


• 多选框：比如支持多个渠道、多种规则生效。

每种类型不仅能展示、还能实时预览效果，这样产品在后台改的时候，不会因为“看不懂这个字段到底是啥”而填错。

3. 每个配置项还要有说明、默认值、排序、是否启用这些“附加属性”

比如说明字段是给人看的，告诉我们这个配置是干嘛的。

默认值是防止读取失败时兜底的。

排序值让我们在后台列表里好找，不然一堆配置乱七八糟的。

“是否启用”是加的一个保险，有些配置值可以保留但临时不生效，方便灰度切换或者留作备选。

4. 最重要的：配置改完必须能“立刻生效”

要是改完还得等发版、等服务重启，那这配置中心跟笔记本有啥区别？

所以我们后面加了热更新机制（这部分我后面会细讲），让配置一改，业务侧立刻拿到新值。

配置中心的数据库设计，我们是这么搞的

配置中心的本质，其实就是“配置的结构化存储 + 可控修改 + 有上下文管理”。

所以数据库是核心。我们一共设计了两个主表：模块表 + 配置项表。当然后续可以加变更记录表之类的，这里先讲核心结构。

1. 模块表：配置的分组归属

配置不能全堆一起，所以我们做了个“模块管理”表，每个模块代表一类业务，比如用户系统、AI 推荐、通知设置、发奖逻辑等。

表结构像下面这样：

CREATE TABLE `config_module` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `name` varchar(100) NOT NULL COMMENT '模块名称',

  `sort` int(11) DEFAULT '0' COMMENT '排序值，越小越靠前',

  `status` tinyint(4) DEFAULT '1' COMMENT '状态 1启用 0禁用',

  `create_time` int(11) NOT NULL,

  `update_time` int(11) DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配置模块分组';

字段说明一下：

• id 就是主键


• name 是模块名，比如“用户系统”、“活动发奖”


• sort 控制在前端显示顺序，方便找


• status 是不是启用这个模块的配置


• 时间字段保留是为了后续查操作记录

2.配置项表：一条配置的所有核心信息

模块分好了之后，接下来就是每个模块下面的具体配置项。我们所有的配置内容，都存在这张 config 表里。

我们当时在设计的时候，就围绕几个问题来定字段的：

• 这个配置是给谁看的？（产品、运营、开发）


• 他们需要怎么填？（输入框？下拉？多选？）


• 填的时候怎么确保不出错？（要不要加参数说明？校验？默认值？）


• 配置项能不能启用/禁用？排序顺序怎么控制？


• 有没有必要展示说明/备注？

最终我们定下了下面这个表结构：

CREATE TABLE `config` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',

  `pid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '所属模块ID',

  `name` varchar(100) NOT NULL COMMENT '配置项名称（展示用）',

  `key` varchar(100) NOT NULL COMMENT '配置项key（英文唯一标识）',

  `value` text COMMENT '配置项当前值',

  `input_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '输入类型：1输入框 2范围 3下拉 4单选 5开关 6多选',

  `param` text COMMENT '参数说明：选项或范围，如 "A-1|B-2|C-3"',

  `desc` varchar(255) DEFAULT '' COMMENT '配置项说明/备注',

  `sort` int(11) DEFAULT '0' COMMENT '排序值（越小越前）',

  `status` tinyint(4) DEFAULT '1' COMMENT '状态：1启用 0禁用',

  `create_time` int(11) NOT NULL,

  `update_time` int(11) DEFAULT NULL,

  PRIMARY KEY (`id`),

  UNIQUE KEY `key` (`key`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统配置项表';

字段说明：

• id：自增主键，没啥说的。


• pid：配置项属于哪个模块（模块表里的 id）。


• name：配置项的中文名，比如“是否展示弹窗”。


• key：这个是英文标识，用来在代码里读取，比如 home.pop.enabled。


• value：配置的当前值，比如 1（开启）或 {"a":1,"b":2}。


• input_type：决定这个配置项在后台怎么展示：
  
  
  
  
  • 1 = 输入框
  
  
  • 2 = 范围（比如“10|100”）
  
  
  • 3 = 下拉框
  
  
  • 4 = 单选按钮
  
  
  • 5 = 开关
  
  
  • 6 = 多选框
  
  
  
  


• param：这个字段就很灵活了，用来定义下拉/单选/多选的选项，或者范围的上下限，比如：
  
  
  
  
  • "中文-zh|英文-en"
  
  
  • "10|100"
  
  
  
  


• desc：配置项的说明，告诉用户这个配置干嘛的，防止乱填。


• sort：排序值，配置项多了之后按顺序展示比较清楚。


• status：这个配置当前是否启用，方便临时关闭某个配置而不删除它。


• create_time / update_time：时间戳，用来做修改记录、日志追踪之类的。


• UNIQUE KEY (key)：保证每个配置 key 唯一，不会撞名。

总体来说，这张表的核心就是：一个配置项，长什么样、值是多少、长得像啥、能不能动，都在这张表里写清楚了。

模块设计：把配置管得清清楚楚，落到后台页面里

前面我们提到，配置中心一定要支持“按模块分组”，不然配置一多，找起来比翻快递单还费劲。

这里就简单说下我们是怎么把“模块”这个概念，真正落到后台界面和数据库结构里的。

我们每个模块其实就是一个大分类，比如：

• 系统配置


• 用户配置


• AI 相关配置


• 活动发奖配置


• 通知推送相关……

每个模块下可以挂多个配置项，类似“一个文件夹里放一类东西”。

我们后台页面上的模块管理界面，大概就长这样：

这里我们可以设计的支持排序、状态控制、修改、删除这些操作。

点击“新增模块”就会弹出这个表单：

看起来非常简洁对不对。上面的模块表结构对应的核心字段就三个：

• 模块名称：展示用，方便识别


• 排序值：用来控制前端列表显示顺序


• 是否启用：可以临时禁用整个模块下的配置项

后台页面支持模块的增删改查，基础功能已足够覆盖大多数业务配置需求。

当然，如果业务后续需要更复杂的结构（比如“系统配置 → 登录模块 → 登录相关配置”这种），我们也可以扩展支持二级模块或模块分组。当前只是保留了基础能力，足够轻量、上手快。

配置项怎么设计的？

有了模块分组之后，接下来的重头戏就是：配置项的核心玩法。

每个配置项，本质上就是一个“可调参数”。比如这些熟悉的问题：

• 用户登录要不要启用谷歌验证？


• 运营活动的推荐数值范围是多少？


• 发奖逻辑该切哪个短信商？

以前这些配置，不是写死在代码里，就是散落在 yml、env 文件里，甚至不同环境各一份，改一次还得发版，改完还得祈祷别出问题。

这次我们干脆做成可视化配置项，页面上就能：

新增、修改、启用/禁用

设置不同类型的输入方式

即填即预览，所见即所得

我们支持的配置类型包括：

• 输入框：适合输入纯文本，比如一个 URL、token、默认值等。


• 范围：用 最小值|最大值 格式，比如推荐人数限制就写成 10|100。


• 下拉选择：多个固定选项，用 | 分隔，比如 中文-zh|英文-en。


• 单选按钮：和下拉差不多，但前端展示为横向圆点，更直观。


• 开关：布尔值场景，1 是开启，0 是关闭。


• 多选框：允许选多个选项，比如某功能适用于多个角色、多个平台。

每种类型在新增配置时都有专属提示，比如范围要填最小|最大，下拉要写选项清单，填完之后还能看到实时预览，确保填的值就是我们想要的。

接下来我们就一个个举例，一边介绍场景，一边实际新增配置项来看效果。

类型一：输入框

适用场景：

输入框是最通用、最基础的配置类型，适合填写纯文本、数字、链接、key 等，不需要做复杂校验，直接存直接用。

常见场景举例：

• default_jump_url：默认跳转链接，比如用户扫码登录后跳去哪个页面。


• login_timeout：用户登录状态超时时间，单位秒。


• system_notice：系统公告文案。


• token_prefix：JWT 或其它 token 的前缀标识。

我们现在来新增一个配置项：

• 所属模块：系统配置


• 配置名称：登录超时（秒）


• 配置 Key：login_timeout


• 输入类型：输入框


• 默认值：600


• 参数说明：留空（输入框不需要）


• 描述：用户登录后多少秒内无操作将自动退出


• 排序值：0


• 是否启用：是

类型二：范围（最小值 | 最大值）

适用场景：

范围类型适合那种“值不能随便填，必须在某个区间内”的配置，比如：

• 推荐系统中：每天最多推荐多少次？


• 活动配置中：用户每次最多能抽几次奖？


• 发奖逻辑中：奖励金额必须在一个上下限之间。

用配置来写这种规则，业务方只要改数字就行，不用再去翻代码或改逻辑，非常方便。

示例配置：推荐数值范围

假设我们现在要配置一个推荐值范围：

• 所属模块：系统配置


• 配置名称：每日推荐数量范围


• 配置 Key：recommend_count_range


• 输入类型：范围


• 默认值：50


• 参数说明：10|100 （表示最小值是 10，最大值是 100）


• 描述：控制推荐系统每天给用户推荐的最小/最大条数


• 排序值：0


• 是否启用：是

我们在页面中选择「输入类型：范围」之后，系统会提示填写参数格式为：

最小值|最大值，例如：10|100

类型三：下拉选择（select）

适用场景：

如果某个配置值只能从一组选项中选一个，比如：

• 默认语言：中文 / 英文 / 日文


• 消息推送渠道：极光 / 个推 / 小米推送


• 推荐策略：粗放型 / 精细化 / AB 测试组

这类配置，业务经常调整，但必须选“规定范围内”的值，用下拉最合适。

示例配置：默认语言设置

我们现在来配置一个「默认语言」的选项：

• 所属模块：系统配置


• 配置名称：默认语言


• 配置 Key：default_language


• 输入类型：下拉选择


• 默认值：zh


• 参数说明：中文-zh|英文-en|日文-jp


• 描述：系统默认语言，决定用户首次进入时的显示语言


• 排序值：0


• 是否启用：是

注意参数说明的格式：

每个选项写成“名称-值”，多个选项用 | 隔开，比如：

中文-zh|英文-en|日文-jp

我们可以随意扩展选项，只要格式统一就行。

类型四：单选按钮（radio）

适用场景：

单选按钮适合那种选项数量不多、用户希望“一眼看清楚当前选的是啥”的配置，比如：

• 登录方式：密码 / 验证码 / 三方授权


• 首页布局：列表 / 瀑布流


• 推送等级：重要 / 普通 / 弱提示

相比下拉，单选按钮更直接，不用点一下再展开，适合管理后台中高频使用的布尔或枚举项

示例配置：登录方式选择

假设我们想设置一个登录方式的配置：

• 所属模块：系统配置


• 配置名称：登录方式


• 配置 Key：login_method


• 输入类型：单选按钮


• 默认值：pwd


• 参数说明：密码登录-pwd|验证码登录-code|三方授权-oauth


• 描述：控制用户使用哪种方式登录


• 排序值：0


• 是否启用：是

参数说明格式：

和下拉一样，用 名称-值 的格式写选项，多个用 | 分隔：

密码登录-pwd|验证码登录-code|三方授权-oauth

类型五：开关（switch）

适用场景：

布尔型逻辑的最爱！

只要我们有 “开关类” 配置，比如：

• 是否开启 AI 推荐功能


• 是否启用登录验证码


• 是否允许用户取消订单


• 是否开启调试日志打印

这些“启用 / 禁用”型的业务控制，都可以直接用开关来配置，后台切换一次立即生效，不用发版，非常方便。

示例配置：启用登录验证码

这次我们来添加一个“是否启用图片验证码”的配置：

• 所属模块：系统配置


• 配置名称：启用图片验证码


• 配置 Key：login_captcha_enabled


• 输入类型：开关


• 默认值：1（1 表示启用，0 表示关闭）


• 参数说明：留空（开关类型不需要）


• 描述：是否对用户登录行为开启图形验证码验证


• 排序值：0


• 是否启用：是

这类配置用处非常多，一些 灰度开关、紧急兜底、临时下线功能 都可以通过这个来做，非常适合给非技术人员使用。

类型六：多选框（checkbox）

适用场景：

当我们希望用户可以勾选多个选项时，单选就不够用了，比如：

• 消息推送支持的渠道：短信 / App / 微信 / 邮件


• 用户允许绑定的第三方平台：微信 / QQ / 微博


• 内容推荐的标签：热门 / 最新 / AI / 精选

多选框让这些“可以组合”的配置变得灵活，谁要开就勾谁，要多选就多选，不受限制。

示例配置：允许的推送渠道

我们来配置一个「支持的消息推送渠道」：

• 所属模块：系统配置


• 配置名称：推送渠道


• 配置 Key：push_channels


• 输入类型：多选框


• 默认值：app,wechat（多个值用英文逗号隔开）


• 参数说明：短信-sms|App-app|微信-wechat|邮件-mail


• 描述：平台支持的推送方式，可多选


• 排序值：0


• 是否启用：是

参数说明格式 & 默认值说明

• 参数格式：展示文本-值 用 | 分隔
  
  

  短信-sms|App-app|微信-wechat|邮件-mail
  
  

  
  


• 默认值：用英文逗号 , 隔开多个值，必须是参数里定义过的值
  
  

  app,wechat
  
  

  
  

配置项列表展示效果（后台页面）

配置添加完以后，在后台配置中心的列表中展示是这样：

每一项都根据类型展示了不同的 UI 组件，页面清晰、可读、可点、可编辑，操作起来一目了然。

而我们的数据库记录示例（config 表）存储为这样的：

每条记录都绑定了模块 ID（这里都挂在“系统配置”模块下），并且通过 input_type 字段区分了类型，param 字段为配置项的结构补充说明（下拉/单选/多选专用），desc 字段用于给配置者提示用途。

至于页面上的 UI 展示逻辑、预览区域怎么动态渲染、后端接口怎么接收和保存这些配置，我这边就不展开一一举例了。

说到底，这套配置中心的重点不是“多高级的交互”，而是“足够简单、稳定、好用”，让我们能快速落地配置项、快速修改参数，而不是天天写死在代码里改个值还要发版。

给产品和运营用的“安全编辑页”

配置项都建好了，页面也能预览，那产品和运营想调参数的时候，是直接去编辑配置项吗？

当然不能。

你想啊，运营只是想把推荐数从 100 调成 50，结果点到 key 了，把 recommend_range 改成 recommend_rang，那后端一拿不到值，整个推荐系统直接罢工了。

所以我们专门做了一套“参数调整页”，就像上图这样的界面，产品和运营只需要点点选项、输个值、开个关，完全不用接触 key 和底层结构，修改也更安全。

这个页面其实是对配置项的“业务层封装”——模块和配置项的创建，还是需要研发来做的。因为只有开发才能知道每个 key 该怎么在代码里接，哪些是支持实时生效的，哪些改了之后要重启服务，业务逻辑怎么走，这些都不是运营自己能处理的。

换句话说：

• 配置项创建时，研发定义 key + 类型 + 默认值 + 参数说明。


• 产品和运营后续修改时，只改值，不动结构，不容易出错。

那我们既然添加了配置项之后，下一步就是把它展示出来，让运营和产品能方便地修改配置、实时查看效果。

我们设计了一个专门的页面，用来承载这些配置项的「操作界面」。页面整体是按模块分 tab 展开的，每个模块下展示自己对应的配置项，表单类型跟配置项定义时保持一致，比如输入框、开关、下拉、多选等一应俱全。

如下图所示，就是我们系统初版配置模块下的实际页面效果：

当然如果某个模块配置太多我们也可以切换为纵向展示：

从上图我们可以看到：

• 每个配置项都有自己的「说明文案」，方便使用者理解配置含义；


• 类型化配置项有明确的 UI 控件，比如「每日推荐数量范围」就是滑动条；


• 实时编辑，保存即生效（根据配置项定义的类型和读取方式）；


• 页面左上角还能切换模块，快速定位。

这个页面是专门为非技术人员设计的，不需要他们懂 key 是什么，也不用关心类型怎么定义，他们只管调值就行了，一切都变得可控又安全。

有了这个配置页之后，产品和运营基本上就能脱离研发，自主修改参数了。接下来我们来聊聊配置值在后端是怎么被接入的。

配置中心只是“存”，真正怎么“用”还得看后端

配置中心做得再强大，最终目的还是要服务业务逻辑。

页面上填的那些 key 和 value 并不是为了好看，它们必须在后端代码里“用起来”，才算真正落地。

那后端是怎么接这些配置的呢？其实就两件事：

比如我们在后台新增了一个配置项：

key: enable_google_auth

value: 1

表示用户登录时是否开启 Google 验证。那后端代码里就可能是这样写的：

func ShouldUseGoogleAuth() bool {

    val := configService.Get("enable_google_auth")

    return val == "1"

}

而且每次新建一个配置项，一定要先让开发把读取逻辑写好，配置才能真正生效。不然页面配得再漂亮，后端代码不接，等于白改。

因此，我们建议配置项的新增一定要有“二次审核”机制——业务逻辑没走通之前，别急着让配置项上线。

配置读取：要读得快，还要改得稳

我们虽然只是做了一个小小的配置中心，但依旧严格遵守几个“配置铁律”：

所以我们最后的设计是：

所有配置值都先读 Redis，Redis 没有再查数据库，查出来的值再写回 Redis。

我们可以简单封装了一个方法来统一读取配置：

func (s *ConfigService) Get(key string) string {

    val, err := redisClient.Get(ctx, "config:"+key).Result()

    if err == redis.Nil {

        val = db.GetConfigFromDB(key)

        redisClient.Set(ctx, "config:"+key, val, time.Hour) // 缓存 1 小时

    }

    return val

}

这样做的好处：

• 性能好：Redis 读取速度快，尤其适合配置这种读多写少的场景；


• 调用方便：业务方不需要知道配置在哪，直接调 configService.Get()；


• 支持热更新：后台一改配置，Redis 一更新，后端逻辑立刻用上新的值。

配置改错了怎么办？我们加了「刷新机制」来兜底

想象一下，有个产品小哥在后台把短信通道从 A 改成了 B，然后 Redis 秒同步，结果是 B 接口根本没打通……

“线上短信全挂了”+“谁改的都不知道”+“运营拉着技术去机房单挑”

这事我们也不是没经历过。

为了防止“手滑即事故”，我们可以引入了 配置刷新机制。

也就是说，后台页面改配置只是“提交更新”，真正生效得靠一个“刷新动作” 。

我们可以设计一种配置刷新方案：保存 ≠ 生效，需要“手动刷新”才能同步

比如我们之前初版采用的模式，更保险一些：

优点是：

• 不怕误操作，有一步确认机会；


• 可接入审批流程；


• 所有操作都有记录，排查问题不含糊。

当然我们也可以设计一个“刷新 API”：

POST /api/config/refresh?key=xxx

POST /api/config/refresh_all

支持单个或批量刷新，用于后台管理或开发联调。

安全兜底机制

除了“刷新机制”，我们还需要做几件事：

总的来说呢，配置中心不是“你点保存我就给你改”，而是一个受控的配置发布系统。

读得快、改得稳、改完能溯源、有通知有审计——这才是一个靠谱的配置中心。

最后的碎碎念

说实话，这套配置中心，说难也不难，说重要吧，也不是业务核心。

但对我们来说，真的很刚需。纯粹就是日常工作中被“配置这点事儿”折磨太久了。 尤其是对业务开发流程不规范的公司来说。

以前在小公司，改个配置就得发版，发版就有几率中奖，一不小心就全服出事。久了大家都怕动，连产品都不敢随便提需求，说白了就是被流程和风险绑住手脚。

后来我们才想明白，像“推荐数量改一下”“开关先关一阵看看效果”这种，完全没必要动代码、改逻辑、走上线流程。给他们一个地方自己调就好了嘛。

所以这套配置中心，说不上啥高级架构，也不是啥大厂必备，但就是解决了我们日常那些“看起来不重要但天天遇到”的小问题。

业务推进更顺了，产品改需求也不再靠嘴说，技术也不用动不动上线连夜发包。这不比啥都强？

更多架构实战、工程化经验和踩坑复盘，我会在公众号 「洛卡卡了」 持续更新。

如果内容对你有帮助，欢迎关注我，我们一起每天学一点，一起进步。

大家好，我是 Guide！在 Java 生态中，Maven 绝对是大家每天都要打交道的“老朋友”。

InterviewGuide 这个开源 AI 项目中，我使用了 Gradle。不过，根据大家的反馈来看还是更愿意使用 Maven 一些。

目前（2026 年 1 月）Maven 4.0 仍处于 Release Candidate 阶段，最新版本为 4.0.0-rc-5（2025 年 11 月 08 日发布），尚未正式 GA（General Availability）。

虽然目前 Maven 4 还处于 Release Candidate（RC）阶段，但它展现出来的特性足以让我们这些长期被 Maven 3 “历史债”折磨的开发者感到兴奋。

一句话总结：Maven 4 要求最低 Java 17 运行环境，通过分离构建与消费模型、树形生命周期等黑科技，彻底告别了臃肿且难以维护的 POM。

下面简单介绍一下 Maven 4 的最重要新特性（基于官方文档和发布记录）：

Build POM 与 Consumer POM 的分离

这是 Maven 4 解决的最大痛点。在 Maven 3 时代，你发布的 pom.xml 既要管“怎么构建”，又要管“别人怎么依赖”，导致发布的元数据极其臃肿，甚至带有大量的 profile 和本地路径。

Maven 4 解决方案：

• Build POM：这就是你本地编辑的 pom.xml（模型升级至 4.1.0）。它包含所有的构建细节，比如插件配置、私有 profile 等。


• Consumer POM：当你执行 deploy 时，Maven 4 会自动生成一个“纯净版”的 pom.xml（固定为 4.0.0 模型）。它去掉了所有插件、build 逻辑和 parent 继承关系，仅保留 GAV 坐标和核心依赖。

默认关闭 ，需显式开启：

mvn deploy -Dmaven.consumer.pom.flatten=true

或在项目根 .mvn/maven-user.properties 中永久配置：

maven.consumer.pom.flatten=true

这样的话，发布的 artifact 更干净，依赖解析更快，生态（Gradle、sbt、IDE、Sonatype 等）兼容性更好，无需再依赖 flatten-maven-plugin 等 hack 方案。

POM 模型升级到 4.1.0 + 多项简化语法

Maven 4 引入了全新的命名空间（**maven.apache.org/POM/4.1.0**…

1. 自动发现子项目

• 新标签 <subprojects> ：正式取代了容易产生术语混淆的 <modules>(标记为 deprecated)。


• 隐式发现 ：如果父项目 packaging=pom 且没有声明子项目，Maven 4 会自动扫描包含 pom.xml 的直接子目录。再也不用手动一行行写子模块名了！

2. 坐标推断（Inference）

在 <parent> 中，如果你按默认路径放置项目，可以省略 version、groupId 甚至整个坐标。Maven 会自动从相对路径推断父 POM 坐标。

3. CI 友好变量原生支持

${revision}、${sha1} 等变量现在是原生一等公民，不需要再写 hack 插件就能直接在命令行定义版本。

构建性能：从线性生命周期到树形并发

Maven 3 的生命周期是线性的，这意味着如果你的项目很大，构建过程就像“老牛拉破车”。

1. 树形生命周期与钩子

Maven 4 将生命周期升级为树形结构，并引入了 before:xxx 和 after:xxx 阶段。你可以更精准地在每个阶段前后绑定插件。

默认还是 Maven 3 时代的线性行为（向后兼容）。

要真正用上树形 + 更细粒度并发，必须显式加参数 -b concurrent（或 --builder concurrent）。

2. 并发构建器 (-b concurrent)

传统的并发构建往往受限于父子依赖。Maven 4 的并发构建器只要依赖模块进入 “Ready” 状态就会立即开跑，不再傻等父模块完成所有阶段。

开发者体验优化

1. 构建恢复 (-r / --resume)

大型项目构建到 90% 挂了？在 Maven 4 里直接 -r 即可从失败处继续，自动跳过已成功的模块。这简直是多模块项目的“救命稻草”。

2. 延迟发布 (deployAtEnd 默认开启)

为了防止出现“半成品”发布（一部分模块发了，另一部分报错没发），Maven 4 默认会在所有模块全部构建成功后才进行最后的统一发布。

3. 官方迁移助手 (mvnup)

担心升级出问题？官方直接给了 mvnup 工具，自动扫描并建议如何将你的 3.x 项目迁移到 4.1.0 模型。

现在该升级吗？

• 生产环境：由于目前还在 RC 阶段，且最低要求 Java 17，建议观望，等正式 GA 之后再小范围灰度。


• 新项目/个人实验：强烈建议开启 POM 4.1.0 进行尝试。特别是 Build/Consumer POM 的分离，能让你的项目元数据管理水平提升一个档次。


• 大厂多模块项目：如果你深陷“Maven 构建慢、POM 维护难”的泥潭，Maven 4 的并发构建和自动子项目发现正是你需要的解药。

面对 Maven 二十年来最大的变动，你最期待哪个功能？或者你已经转向了 Gradle？欢迎在评论区留言，我们一起“对齐”一下！

相关地址：

• Maven 发布记录：maven.apache.org/ref/


• 迁移到 Maven4：maven.apache.org/guides/mini…


• Maven4 介绍：maven.apache.org/whatsnewinm…

每到节假日期间，一二线城市返乡、外出游玩的人们几乎都面临着一个问题：抢火车票！

12306 抢票，极限并发带来的思考

虽然现在大多数情况下都能订到票，但是放票瞬间即无票的场景，相信大家都深有体会。

尤其是春节期间，大家不仅使用 12306，还会考虑“智行”和其他的抢票软件，全国上下几亿人在这段时间都在抢票。

“12306 服务”承受着这个世界上任何秒杀系统都无法超越的 QPS，上百万的并发再正常不过了！

笔者专门研究了一下“12306”的服务端架构，学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在 100 万人同时抢 1 万张火车票时，系统提供正常、稳定的服务。

Github代码地址：

https://github.com/GuoZhaoran/spikeSystem

大型高并发系统架构

高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段（双火机房、节点容错、服务器灾备等）保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。

下边是一个简单的示意图：

负载均衡简介

上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡。

①OSPF（开放式最短链路优先）是一个内部网关协议（Interior Gateway Protocol，简称 IGP）

OSPF 通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，OSPF 会自动计算路由接口上的 Cost 值，但也可以通过手工指定该接口的 Cost 值，手工指定的优先于自动计算的值。

OSPF 计算的 Cost，同样是和接口带宽成反比，带宽越高，Cost 值越小。到达目标相同 Cost 值的路径，可以执行负载均衡，最多 6 条链路同时执行负载均衡。

②LVS （Linux Virtual Server）

它是一种集群（Cluster）技术，采用 IP 负载均衡技术和基于内容请求分发技术。

调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。

③Nginx

想必大家都很熟悉了，是一款非常高性能的 HTTP 代理/反向代理服务器，服务开发中也经常使用它来做负载均衡。

Nginx 实现负载均衡的方式主要有三种：

• 轮询


• 加权轮询


• IP Hash 轮询

下面我们就针对 Nginx 的加权轮询做专门的配置和测试。

Nginx 加权轮询的演示

Nginx 实现负载均衡通过 Upstream 模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。

下面是一个加权轮询负载的配置，我将在本地的监听 3001-3004 端口，分别配置 1，2，3，4 的权重：

#配置负载均衡

    upstream load_rule {

       server 127.0.0.1:3001 weight=1;

       server 127.0.0.1:3002 weight=2;

       server 127.0.0.1:3003 weight=3;

       server 127.0.0.1:3004 weight=4;

    }

    ...

    server {

    listen       80;

    server_name  load_balance.com http://www.load_balance.com;

    location / {

       proxy_pass http://load_rule;

    }

}

我在本地 /etc/hosts 目录下配置了 http://www.load_balance.com 的虚拟域名地址。

接下来使用 Go 语言开启四个 HTTP 端口监听服务，下面是监听在 3001 端口的 Go 程序，其他几个只需要修改端口即可：

package main



import (

    "net/http"

    "os"

    "strings"

)



func main() {

    http.HandleFunc("/buy/ticket", handleReq)

    http.ListenAndServe(":3001", nil)

}



//处理请求函数,根据请求将响应结果信息写入日志

func handleReq(w http.ResponseWriter, r *http.Request) {

    failedMsg :=  "handle in port:"

    writeLog(failedMsg, "./stat.log")

}



//写入日志

func writeLog(msg string, logPath string) {

    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)

    defer fd.Close()

    content := strings.Join([]string{msg, "\r\n"}, "3001")

    buf := []byte(content)

    fd.Write(buf)

}

我将请求的端口日志信息写到了 ./stat.log 文件当中，然后使用 AB 压测工具做压测：

ab -n 1000 -c 100 http://www.load_balance.com/buy/ticket

统计日志中的结果，3001-3004 端口分别得到了 100、200、300、400 的请求量。

这和我在 Nginx 中配置的权重占比很好的吻合在了一起，并且负载后的流量非常的均匀、随机。

具体的实现大家可以参考 Nginx 的 Upsteam 模块实现源码，这里推荐一篇文章《Nginx 中 Upstream 机制的负载均衡》：

https://www.kancloud.cn/digest/understandingnginx/202607

秒杀抢购系统选型

回到我们最初提到的问题中来：火车票秒杀系统如何在高并发情况下提供正常、稳定的服务呢？

从上面的介绍我们知道用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的 QPS 也是非常高的。如何将单机性能优化到极致呢？

要解决这个问题，我们就要想明白一件事： 通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段。

我们系统要做的事情是要保证火车票订单不超卖、不少卖，每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。

这三个阶段的先后顺序该怎么分配才更加合理呢？我们来分析一下：

下单减库存

当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。

这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。

但是这样也会产生一些问题：

• 在极限并发情况下，任何一个内存操作的细节都至关影响性能，尤其像创建订单这种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的。


• 如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制 IP 和用户的购买订单数量，这也不算是一个好方法。

支付减库存

如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单。

当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘 IO。

预扣库存

从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库 IO。

那么有没有一种不需要直接操作数据库 IO 的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？

我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。

订单的生成是异步的，一般都会放到 MQ、Kafka 这样的即时消费队列中处理，订单量比较少的情况下，生成订单非常快，用户几乎不用排队。

扣库存的艺术

从上面的分析可知，显然预扣库存的方案最合理。我们进一步分析扣库存的细节，这里还有很大的优化空间，库存存在哪里？怎样保证高并发下，正确的扣库存，还能快速的响应用户请求？

在单机低并发情况下，我们实现扣库存通常是这样的：

为了保证扣库存和生成订单的原子性，需要采用事务处理，然后取库存判断、减库存，最后提交事务，整个流程有很多 IO，对数据库的操作又是阻塞的。

这种方式根本不适合高并发的秒杀系统。接下来我们对单机扣库存的方案做优化：本地扣库存。

我们把一定的库存量分配到本地机器，直接在内存中减库存，然后按照之前的逻辑异步创建订单。

改进过之后的单机系统是这样的：

这样就避免了对数据库频繁的 IO 操作，只在内存中做运算，极大的提高了单机抗并发的能力。

但是百万的用户请求量单机是无论如何也抗不住的，虽然 Nginx 处理网络请求使用 Epoll 模型，c10k 的问题在业界早已得到了解决。

但是 Linux 系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。

上面我们提到了 Nginx 的加权均衡策略，我们不妨假设将 100W 的用户请求量平均均衡到 100 台服务器上，这样单机所承受的并发量就小了很多。

然后我们每台机器本地库存 100 张火车票，100 台服务器上的总库存还是 1 万，这样保证了库存订单不超卖，下面是我们描述的集群架构：

问题接踵而至，在高并发情况下，现在我们还无法保证系统的高可用，假如这 100 台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。

要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存。

有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的“Buffer 库存”用来防止机器中有机器宕机的情况。

我们结合下面架构图具体分析一下：

我们采用 Redis 存储统一库存，因为 Redis 的性能非常高，号称单机 QPS 能抗 10W 的并发。

在本地减库存以后，如果本地有订单，我们再去请求 Redis 远程减库存，本地减库存和远程减库存都成功了，才返回给用户抢票成功的提示，这样也能有效的保证订单不会超卖。

当机器中有机器宕机时，因为每个机器上有预留的 Buffer 余票，所以宕机机器上的余票依然能够在其他机器上得到弥补，保证了不少卖。

Buffer 余票设置多少合适呢，理论上 Buffer 设置的越多，系统容忍宕机的机器数量就越多，但是 Buffer 设置的太大也会对 Redis 造成一定的影响。

虽然 Redis 内存数据库抗并发能力非常高，请求依然会走一次网络 IO，其实抢票过程中对 Redis 的请求次数是本地库存和 Buffer 库存的总量。

因为当本地库存不足时，系统直接返回用户“已售罄”的信息提示，就不会再走统一扣库存的逻辑。

这在一定程度上也避免了巨大的网络请求量把 Redis 压跨，所以 Buffer 值设置多少，需要架构师对系统的负载能力做认真的考量。

代码演示

Go 语言原生为并发设计，我采用 Go 语言给大家演示一下单机抢票的具体流程。

初始化工作

Go 包中的 Init 函数先于 Main 函数执行，在这个阶段主要做一些准备性工作。

我们系统需要做的准备工作有：初始化本地库存、初始化远程 Redis 存储统一库存的 Hash 键值、初始化 Redis 连接池。

另外还需要初始化一个大小为 1 的 Int 类型 Chan，目的是实现分布式锁的功能。

也可以直接使用读写锁或者使用 Redis 等其他的方式避免资源竞争，但使用 Channel 更加高效，这就是 Go 语言的哲学：不要通过共享内存来通信，而要通过通信来共享内存。

Redis 库使用的是 Redigo，下面是代码实现：

...

//localSpike包结构体定义

package localSpike



type LocalSpike struct {

    LocalInStock     int64

    LocalSalesVolume int64

}

...

//remoteSpike对hash结构的定义和redis连接池

package remoteSpike

//远程订单存储健值

type RemoteSpikeKeys struct {

    SpikeOrderHashKey string    //redis中秒杀订单hash结构key

    TotalInventoryKey string    //hash结构中总订单库存key

    QuantityOfOrderKey string   //hash结构中已有订单数量key

}



//初始化redis连接池

func NewPool() *redis.Pool {

    return &redis.Pool{

        MaxIdle:   10000,

        MaxActive: 12000, // max number of connections

        Dial: func() (redis.Conn, error) {

            c, err := redis.Dial("tcp", ":6379")

            if err != nil {

                panic(err.Error())

            }

            return c, err

        },

    }

}

...

func init() {

    localSpike = localSpike2.LocalSpike{

        LocalInStock:     150,

        LocalSalesVolume: 0,

    }

    remoteSpike = remoteSpike2.RemoteSpikeKeys{

        SpikeOrderHashKey:  "ticket_hash_key",

        TotalInventoryKey:  "ticket_total_nums",

        QuantityOfOrderKey: "ticket_sold_nums",

    }

    redisPool = remoteSpike2.NewPool()

    done = make(chanint, 1)

    done <- 1

}

本地扣库存和统一扣库存

本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回 Bool 值：

package localSpike

//本地扣库存,返回bool值

func (spike *LocalSpike) LocalDeductionStock() bool{

    spike.LocalSalesVolume = spike.LocalSalesVolume + 1

    return spike.LocalSalesVolume < spike.LocalInStock

}

注意这里对共享数据 LocalSalesVolume 的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用 Channel 来实现，这块后边会讲。

统一扣库存操作 Redis，因为 Redis 是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合 Lua 脚本打包命令，保证操作的原子性：

package remoteSpike

......

const LuaScript = `

        local ticket_key = KEYS[1]

        local ticket_total_key = ARGV[1]

        local ticket_sold_key = ARGV[2]

        local ticket_total_nums = tonumber(redis.call('HGET', ticket_key, ticket_total_key))

        local ticket_sold_nums = tonumber(redis.call('HGET', ticket_key, ticket_sold_key))

        -- 查看是否还有余票,增加订单数量,返回结果值

       if(ticket_total_nums >= ticket_sold_nums) then

            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)

        end

        return0

`

//远端统一扣库存

func (RemoteSpikeKeys *RemoteSpikeKeys) RemoteDeductionStock(conn redis.Conn) bool {

    lua := redis.NewScript(1, LuaScript)

    result, err := redis.Int(lua.Do(conn, RemoteSpikeKeys.SpikeOrderHashKey, RemoteSpikeKeys.TotalInventoryKey, RemoteSpikeKeys.QuantityOfOrderKey))

    if err != nil {

        returnfalse

    }

    return result != 0

}

我们使用 Hash 结构存储总库存和总销量的信息，用户请求过来时，判断总销量是否大于库存，然后返回相关的 Bool 值。

在启动服务之前，我们需要初始化 Redis 的初始库存信息：

hmset ticket_hash_key "ticket_total_nums" 10000 "ticket_sold_nums" 0

响应用户信息

我们开启一个 HTTP 服务，监听在一个端口上：

package main

...

func main() {

    http.HandleFunc("/buy/ticket", handleReq)

    http.ListenAndServe(":3005", nil)

}

上面我们做完了所有的初始化工作，接下来 handleReq 的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。

package main

//处理请求函数,根据请求将响应结果信息写入日志

func handleReq(w http.ResponseWriter, r *http.Request) {

    redisConn := redisPool.Get()

    LogMsg := ""

    <-done

    //全局读写锁

    if localSpike.LocalDeductionStock() && remoteSpike.RemoteDeductionStock(redisConn) {

        util.RespJson(w, 1,  "抢票成功", nil)

        LogMsg = LogMsg + "result:1,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)

    } else {

        util.RespJson(w, -1, "已售罄", nil)

        LogMsg = LogMsg + "result:0,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)

    }

    done <- 1



    //将抢票状态写入到log中

    writeLog(LogMsg, "./stat.log")

}



func writeLog(msg string, logPath string) {

    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)

    defer fd.Close()

    content := strings.Join([]string{msg, "\r\n"}, "")

    buf := []byte(content)

    fd.Write(buf)

}

前边提到我们扣库存时要考虑竞态条件，我们这里是使用 Channel 避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了 ./stat.log 文件方便做压测统计。

单机服务压测

开启服务，我们使用 AB 压测工具进行测试：

ab -n 10000 -c 100 http://127.0.0.1:3005/buy/ticket

下面是我本地低配 Mac 的压测信息：

This is ApacheBench, Version 2.3 <$revision: 1826891="">

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/



Benchmarking 127.0.0.1 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 10000 requests

Finished 10000 requests





Server Software:

Server Hostname:        127.0.0.1

Server Port:            3005



Document Path:          /buy/ticket

Document Length:        29 bytes



Concurrency Level:      100

Time taken for tests:   2.339 seconds

Complete requests:      10000

Failed requests:        0

Total transferred:      1370000 bytes

HTML transferred:       290000 bytes

Requests per second:    4275.96 [#/sec] (mean)

Time per request:       23.387 [ms] (mean)

Time per request:       0.234 [ms] (mean, across all concurrent requests)

Transfer rate:          572.08 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    8  14.7      6     223

Processing:     2   15  17.6     11     232

Waiting:        1   11  13.5      8     225

Total:          7   23  22.8     18     239



Percentage of the requests served within a certain time (ms)

  50%     18

  66%     24

  75%     26

  80%     28

  90%     33

  95%     39

  98%     45

  99%     54

 100%    239 (longest request)

根据指标显示，我单机每秒就能处理 4000+ 的请求，正常服务器都是多核配置，处理 1W+ 的请求根本没有问题。

而且查看日志发现整个服务过程中，请求都很正常，流量均匀，Redis 也很正常：

//stat.log

...

result:1,localSales:145

result:1,localSales:146

result:1,localSales:147

result:1,localSales:148

result:1,localSales:149

result:1,localSales:150

result:0,localSales:151

result:0,localSales:152

result:0,localSales:153

result:0,localSales:154

result:0,localSales:156

...

总结回顾

总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略

完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户，还有用户在订单有效期内不支付，释放订单，补充到库存等等。

我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对 DB 数据库 IO 的操作。

对 Redis 网络 IO 的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。

我觉得其中有两点特别值得学习总结：

①负载均衡，分而治之

通过负载均衡，将不同的流量划分到不同的机器上，每台机器处理好自己的请求，将自己的性能发挥到极致。

这样系统的整体也就能承受极高的并发了，就像工作的一个团队，每个人都将自己的价值发挥到了极致，团队成长自然是很大的。

②合理的使用并发和异步

自 Epoll 网络架构模型解决了 c10k 问题以来，异步越来越被服务端开发人员所接受，能够用异步来做的工作，就用异步来做，在功能拆解上能达到意想不到的效果。

这点在 Nginx、Node.JS、Redis 上都能体现，他们处理网络请求使用的 Epoll 模型，用实践告诉了我们单线程依然可以发挥强大的威力。

服务器已经进入了多核时代，Go 语言这种天生为并发而生的语言，完美的发挥了服务器多核优势，很多可以并发处理的任务都可以使用并发来解决，比如 Go 处理 HTTP 请求时每个请求都会在一个 Goroutine 中执行。

总之，怎样合理的压榨 CPU，让其发挥出应有的价值，是我们一直需要探索学习的方向。

前言

最近两年左右的时间，我一口气肝了8个实现项目。

包含了各种业界常见的技术，比如：SpringBoot、SpringCloud、SpringCloud Alibaba、Mybatis、JPA、Redis、MongoDB、ElasticSearch、MySQL、PostgreSQL、Minio、Caffine、RocketMQ、Prometheus、Grafana、ELK、skywalking、Sentinel、Nacos、Redisson、shardingsphere、HikariCP、guava、WebFlux、nacos、Sentinel、WebSocket、Gateway、Nginx、Docker、Spring AI、Spring AI Alibaba等等，非常值得一看。

今天给大家介绍一下这些项目，感兴趣的小伙伴，可以一起交流学习一下，干货满满。

1 100万QPS短链系统

使用技术：JDK21、SpringBoot3.5.3、JPA、Redis、布隆过滤器、Sentinel、Nacos、Redisson、shardingsphere、HikariCP、guava、Prometheus等。

目前设计了32个数据库，每个数据库包含了256张表。

每天可支持2.6亿以上的数据写入。

100万QPS短链系统的系统架构图如下：

技术亮点：

该项目的亮点是：

基于时间片的布隆过滤器流程图如下：

短链系统平滑扩容方案如下：

通过这个项目，可以学到很多高并发、流量评估、分库分表、多级缓存、多级布隆过滤器、限流、熔断、多线程、监控、报警、数据扩容、集群、广播消息、单元测试编写等多方面的知识。

目前这个项目包含两端代码：

想进大厂的小伙伴们，一定不要错过这个项目，里面有很多加分项。

点击这里获取项目源代码和教程：www.susan.net.cn/project

2 SaaS点餐系统

使用技术：JDK21、SpringBoot3.4.3、SpringCloud、SpringCloud Alibaba、Gateway、Mybatis、PostgesSQL、Redis、RocketMQ、ElasticSearch、Knife4j、Prometheus、Grafana、Minio、数据隔离等。

SaaS点餐系统是一套：DDD开发模式+多租户+PostgesSQL 的复杂微服务系统。

包含了9个微服务。

系统整体架构如下：

数据隔离方案如下：

DDD开发模式的代码示例：

通过这个项目可以掌握DDD开发模型、多租户数据隔离的方案实现、PostgresSQL数据库的使用，还有微服务之间的数据交换，网关服务的统一处理，以及复杂系统的职责领域的划分。

运行效果：

3 商城微服务系统

susan_mall_cloud是微服务项目。

使用了目前业界比较新的技术：JDK17、Spring6、SpringBoot3.3.5、SpringCloud2024、SpringCloud Alibaba2023.0.1.0。

微服务后端包含了：

• susan-mall-common （公共文件）


• susan-mall-gateway （网关服务）


• susan-mall-basic (基础服务)


• susan-mall-auth （权限服务，包含用户和权限相关的）


• susan-mall-product （商品服务）


• susan-mall-order （订单服务）


• susan-mall-pay （支付服务）


• susan-mall-member （会员服务）


• susan-mall-marketing （营销服务）


• susan-mall-admin（后台管理系统API）


• susan-mall-mobile（移动端API）

这个版本在商城已有技术基础之上，又增加了：SpringCloud Gateway、WebFlux、Seata、Skywaking、OpenFeign、Loadbalancer、Sentinel、Nacos、Canal、xxl-job、Prometheus、K8S等。

项目架构图：

目前包含了多端代码：

下面是商城小程序真实的截图：

看起来是不是非常专业？

商城微服务项目很复杂，包含了目前业界微服务分布式系统中使用最主流的技术，强烈推荐一下。

无论在工作中，还是面试中，都可以作为加分项。

特别是SpringCloud Gateway中WebFlux的使用，微服务之间的异常处理，以及微服务之间的通信，都很值得一看。

4 商城系统

商城系统目前包含了：SpringBoot后端 + Vue管理后台 + uniapp小程序 ，三个端的完整代码。

商城项目中包含了：基于Docker部署教程、域名解析教程、按环境隔离、网络爬虫、推荐算法、支付宝支付、分库分表、分片算法优化、手写动态定时任务、手写通用分页组件、JWT登录验证、数据脱敏、动态workId、hanlp敏感词校验，手写分布式ID生成器、分布式限流、手写Mybatis插件、两级缓存提升性能、MQ消息通信、ES商品搜索、OSS服务对接、失败自动重试机制、接口幂等性处理、百万数据excel导出、WebSocket消息推送、用户异地登录检测、freemarker模版邮件发送、代码生成工具、重复请求自动拦截、自定义金额校验注解等等一系列功能。

使用的技术：

商城系统的系统架构图如下：

包含了：

• 应用层：小程序、移动端H5、管理后台


• 网关层：Nginx反向代理和负载均衡


• 服务层：API服务、Job服务 & mq消费者服务


• 数据存储层：susan_mall库MySQL主从、susan_mall_order库MySQL分库分表、MongoDB保存商品详情、Minio存储文件


• 中间件层：Redis集群、RocketMQ、ElasticSearch、Nacos（注册中间 & 配置中心）

商城系统的技术架构图如下：

使用的都是目前业界非常主流和常用的技术，这些技术大部分公司目前都在使用。

商城系统可以帮你真正增加很多企业级项目经验。

功能亮点：

商城项目无论是毕业设计，还是面试，还是实际工作中，都非常值得一看。

商城项目使用了目前非常主流的技术，手写了很多底层的代码，设计模式、自定义了很多拦截器、过滤器、转换器、监听器等，很多代码可以搬到实际的工作中。

目前星球中包含了商城项目从0~1的完整开发教程，小白也可以直接上手。

星球中有些小伙伴，通过这个项目拿到了非常不错的offer。

点击这里获取项目源代码和教程：www.susan.net.cn/project

5. 秒杀系统

苏三的秒杀系统是专门为高并发而生的。

目前使用的技术有：SpringBoot、Redis、Redission、lua、RocketMQ、ElasticSearch、JWT、freemarker、themelaf、html、vue、element-ui等。

功能包括：商品预热、商品秒杀、分布式锁、MQ异步下单、限流、失败重试、预扣库存、数据一致性处理等。

涉及到了高并发的多种技术，特别是对页面静态化，倒计时、秒杀按钮控制、分布式锁、预扣库存、MQ处理、数据一致性等，会有比较大的收获。

秒杀系统的系统架构图：

可以帮你增加高并发的工作经验，也可以写到你的简历中。

秒杀系统在面试或者工作中，会经常遇到，非常有参考价值。

6 刷题吧小程序

IT刷题吧是我用AI花了几天时间，设计和开发了一款小程序。

效果图如下：

为了帮助大家能够快速的掌握使用AI开发项目的技巧，提升开发效率，能够先人一步，变成全栈开发工程师。

无论是自己接私活，还是开发公司的项目，都能够用更少的时间，写出更多，更有价值的代码。

苏三在知识星球中给小伙伴们，通过IT刷题吧项目，专门开设了一个AI开发课程。

你看完之后，会发现打开了一扇通向新世界的大门。（有很多惊喜）

这个课程会包含如下内容：

• 如何用AI设计产品原型的？


• 如何用AI生成小程序端和后端的代码结构的？


• 如何用AI生成后端的表结构？


• 如何用AI生成小程序和后端代码？


• 如何生成一套完整的可运行的代码？


• 如何基于图片生成想要的代码？


• 如何搞定小程序页面中的图片问题？


• 如何让小程序端和后端代码调通？


• 生成的代码不理想怎么办？


• 如果在开发过程中遇到了一些问题，用AI如何解决问题？


• 如何生成测试数据？


• 如何制定代码开发规范？


• AI开发工具的使用方法


• AI开发工具卡顿怎么办？


• 如何运行项目？


• 如何上线部署项目？
  等等。。。

星球中会交付如下内容：

目前已经全部开发完。

使用AI开发这个项目，从0~1的开发和部署教程。
问题答疑。
通过这个项目，你可以学到使用AI开发项目的具体方法。

如果你掌握了这些方法，开发其他的小程序绰绰有余。

这个项目有极大的价值。

授人予鱼，不如授人以渔。

光是学会这个项目，就有极大的价值。

7. 苏三的demo项目

这个项目包含了一些工作中常用的技术点，有很多非常有参考价值的示例。

涵盖：Spring、Mybatis、多线程、事务、常用工具、设计模式、http请求、lamda、io、excel、泛型、注解等多个方面。

本项目的宗旨是分享实际工作中，非常实用的代码技巧，能够让你写出更优雅高效的代码。

此外，后面会收录一下面试中，尤其是笔试中经常会被问题到的代码片段和算法。

8. 代码生成器项目

这是一个基于Spring Boot的智能代码生成器，能够根据数据库表结构自动生成完整的Java Web项目代码，极大提升开发效率，让开发者专注于业务逻辑而非重复的CRUD代码编写。

我们用这个代码生成器，可以通过数据库表，一键直接生成controller、service、mapper、entity、菜单sql、vue页面等。

使用的技术：SpringBoot、MyBatis、Apache Velocity、Swagger2、Lombok、Druid、Maven等。

我们在日常开发中，把数据库表设计好了之后，然后通过该工具，能够快速生成一个可以直接运行的CRUD代码。

毫不夸张的说，如果在项目中使用它，可以让你的开发效率快速提升，我们真的可以少写30%的代码。

在实际工作中，非常有价值。

点击这里获取项目源代码和教程：www.susan.net.cn/project

前言

这篇文章跟大家一起聊聊打印优质日志的10条军规，希望对你会有所帮助。

第1条：格式统一

反例（管理看到会扣钱）：

log.info("start process");

log.error("error happen"); 

无时间戳，无上下文。

正解代码：

<!-- logback.xml核心配置 -->

<pattern>

    %d{yy-MM-dd HH:mm:ss.SSS} 

    |%X{traceId:-NO_ID} 

    |%thread 

    |%-5level 

    |%logger{36} 

    |%msg%n

</pattern>

在logback.xml中统一配置了日志的时间格式、tradeId，线程、等级、日志详情都信息。

日志的格式统一了，更方便点位问题。

第2条：异常必带堆栈

反例（同事看了想打人）：

try {

    processOrder();

} catch (Exception e) {

    log.error("处理失败"); 

}

出现异常了，日志中没打印任何的异常堆栈信息。

相当于自己把异常吃掉了。

非常不好排查问题。

正确姿势：

log.error("订单处理异常 orderId={}", orderId, e); // e必须存在！

日志中记录了出现异常的订单号orderId和异常的堆栈信息e。

第3条：级别合理

反面教材：

log.debug("用户余额不足 userId={}", userId); // 业务异常应属WARN

log.error("接口响应稍慢"); // 普通超时属INFO

接口响应稍慢，打印了error级别的日志，显然不太合理。

正常情况下，普通超时属INFO级别。

级别定义表：

第4条：参数完整

反例（让运维骂娘）：

log.info("用户登录失败");

上面这个日志只打印了“用户登录失败”这个文案。

谁在哪登录失败？

侦探式日志：

log.warn("用户登录失败 username={}, clientIP={}, failReason={}", 

    username, clientIP, "密码错误次数超限");

登录失败的业务场景，需要记录哪个用户，ip是多少，在什么时间，登录失败了，失败的原因是什么。

时间在logback.xml中统一配置了格式。

这样才方便快速定位问题：

第5条：数据脱敏

血泪案例：

某同事打印日志泄露用户手机号被投诉。

我在记录的日志中，需要对一下用户的个人敏感数据做脱敏处理。

例如下面这样：

// 脱敏工具类

public class LogMasker {

    public static String maskMobile(String mobile) {

        return mobile.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2");

    }

}



// 使用示例

log.info("用户注册 mobile={}", LogMasker.maskMobile("13812345678"));

第6条：异步保性能

问题复现

某次秒杀活动中直接同步写日志，导致大量线程阻塞：

log.info("秒杀请求 userId={}, itemId={}", userId, itemId); 

高并发下IO阻塞。

致命伤害分析：

正确示范（三步配置法）

步骤1：logback.xml配置异步通道

<!-- 异步Appender核心配置 -->  

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">  

    <!-- 不丢失日志的阈值：当队列剩余容量＜此值时，TRACE/DEBUG级别日志将被丢弃 -->  

    <discardingThreshold>0</discardingThreshold>  

    <!-- 队列深度：建议设为 (最大并发线程数 × 2) -->  

    <queueSize>4096</queueSize>  

    <!-- 关联真实Appender -->  

    <appender-ref ref="FILE"/>  

</appender>  

步骤2：日志输出优化代码

// 无需前置判断，框架自动处理  

log.debug("接收到MQ消息：{}", msg.toSimpleString()); // 自动异步写入队列  



// 不应做复杂计算后再打印（异步前仍在业务线程执行）  

// 错误做法：  

log.debug("详细内容：{}", computeExpensiveLog());  

流程图如下：

步骤3：性能关键参数公式

最大内存占用 ≈ 队列长度 × 平均单条日志大小  

推荐队列深度 = 峰值TPS × 容忍最大延迟(秒)  

例如：10000 TPS × 0.5s容忍 ⇒ 5000队列大小  

风险规避策略

第7条：链路追踪

混沌场景：

跨服务调用无法关联日志。

我们需要有链路追踪方案。

全链路方案：

// 拦截器注入traceId

MDC.put("traceId", UUID.randomUUID().toString().substring(0,8));



// 日志格式包含traceId

<pattern>%d{HH:mm:ss} |%X{traceId}| %msg%n</pattern>

可以在MDC中设置traceId。

后面可以通过traceId全链路追踪日志。

流程图如下：

第8条：动态调参

半夜重启的痛：

线上问题需要临时开DEBUG日志，比如：查询用户的某次异常操作的日志。

热更新方案：

@GetMapping("/logLevel")

public String changeLogLevel(

    @RequestParam String loggerName, 

    @RequestParam String level) {

    

    Logger logger = (Logger) LoggerFactory.getLogger(loggerName);

    logger.setLevel(Level.valueOf(level)); // 立即生效

    return "OK";

}

有时候我们需要临时打印DEBUG日志，这就需要有个动态参数控制了。

否则每次调整打印日志级别都需要重启服务，可能会影响用户的正常使用。

journey

    title 日志级别动态调整

    section 旧模式

        发现问题 --> 修改配置 --> 重启应用 --> 丢失现场

    section 新模式

        发现问题 --> 动态调整 --> 立即生效 --> 保持现场

第9条：结构化存储

混沌日志：

用户购买了苹果手机 订单号1001 金额8999

上面的日志拼接成了一个字符串，虽说中间有空格分隔了，但哪些字段对应了哪些值，看起来不是很清楚。

我们在存储日志的时候，需要做结构化存储，方便快速的查询和搜索。

机器友好式日志：

{

  "event": "ORDER_CREATE",

  "orderId": 1001,

  "amount": 8999,

  "products": [{"name":"iPhone", "sku": "A123"}]

}

这里使用了json格式存储日志。

日志中的数据一目了然。

第10条：智能监控

最失败案例：

某次用户开通会员操作，错误日志堆积3天才被发现，黄花菜都凉了。

我们需要在项目中引入智能监控。

ELK监控方案：

报警规则示例：

ERROR日志连续5分钟 > 100条 → 电话告警  

WARN日志持续1小时 → 邮件通知

总结

研发人员的三大境界：

最后的灵魂拷问：

下次线上故障时，你的日志能让新人5分钟定位问题吗？

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

MCP 与 Skill 深度对比：AI Agent 的两种扩展哲学

用 AI Agent 工具（Claude Code、Cursor、Windsurf 等）的时候，经常会遇到两个概念：

• MCP（Model Context Protocol）


• Skill（Agent Skill）

它们看起来都是"扩展 AI 能力"的方式，但具体有什么区别？为什么需要两套机制？什么时候该用哪个？

这篇文章会从设计哲学、技术架构、使用场景三个维度，把这两个概念彻底讲清楚。

一句话区分

先给个简单的定位：

MCP 解决"连接"问题：让 AI 能访问外部世界
Skill 解决"方法论"问题：教 AI 怎么做某类任务

用 Anthropic 官方的说法：

"MCP connects Claude to external services and data sources. Skills provide procedural knowledge—instructions for how to complete specific tasks or workflows."

打个比方：MCP 是 AI 的"手"（能触碰外部世界），Skill 是 AI 的"技能书"（知道怎么做某件事）。

你需要两者配合：MCP 让 AI 能连接数据库，Skill 教 AI 怎么分析查询结果。

MCP：AI 应用的 USB-C 接口

MCP 是什么

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月发布的开源协议，用于标准化 AI 应用与外部系统的交互方式。

官方的比喻是"AI 应用的 USB-C 接口"——就像 USB-C 提供了一种通用的方式连接各种设备，MCP 提供了一种通用的方式连接各种工具和数据源。

关键点：MCP 不是 Claude 专属的。

它是一个开放协议，理论上任何 AI 应用都可以实现。截至 2025 年初，已经被多个平台采用：

• Anthropic: Claude Desktop、Claude Code


• OpenAI: ChatGPT、Agents SDK、Responses API


• Google: Gemini SDK


• Microsoft: Azure AI Services


• 开发工具: Zed、Replit、Codeium、Sourcegraph

到 2025 年 2 月，已经有超过 1000 个开源 MCP 连接器。

MCP 的架构

MCP 基于 JSON-RPC 2.0 协议，采用客户端-主机-服务器（Client-Host-Server）架构：

┌─────────────────────────────────────────────────────────┐

│                        Host                              │

│              (Claude Desktop / Cursor)                   │

│                                                          │

│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │

│  │   Client    │  │   Client    │  │   Client    │      │

│  │  (GitHub)   │  │ (Postgres)  │  │  (Sentry)   │      │

│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘      │

└─────────┼────────────────┼────────────────┼─────────────┘

          │                │                │

          ▼                ▼                ▼

    ┌───────────┐    ┌───────────┐    ┌───────────┐

    │MCP Server │    │MCP Server │    │MCP Server │

    │ (GitHub)  │    │(Postgres) │    │ (Sentry)  │

    └───────────┘    └───────────┘    └───────────┘

• Host：用户直接交互的应用（Claude Desktop、Cursor、Windsurf）


• Client：Host 应用中管理与特定 Server 通信的组件


• Server：连接外部系统的桥梁（数据库、API、本地文件等）

MCP 的三个核心原语

MCP 定义了三种 Server 可以暴露的原语：

1. Tools（工具）—— 模型控制

可执行的函数，AI 可以调用来执行操作。

{

  "name": "query_database",

  "description": "Execute SQL query on the database",

  "parameters": {

    "type": "object",

    "properties": {

      "sql": { "type": "string" }

    }

  }

}

AI 决定什么时候调用这些工具。比如用户问"这个月的收入是多少"，AI 判断需要查数据库，就会调用 query_database 工具。

2. Resources（资源）—— 应用控制

数据源，为 AI 提供上下文信息。

{

  "uri": "file:///Users/project/README.md",

  "name": "Project README",

  "mimeType": "text/markdown"

}

资源由应用控制何时加载。用户可以通过 @ 引用资源，类似于引用文件。

3. Prompts（提示）—— 用户控制

预定义的提示模板，帮助结构化与 AI 的交互。

{

  "name": "code_review",

  "description": "Review code for bugs and security issues",

  "arguments": [

    { "name": "code", "required": true }

  ]

}

用户显式触发这些提示，类似于 Slash Command。

MCP 与 Function Calling 的关系

很多人会问：MCP 和 OpenAI 的 Function Calling、Anthropic 的 Tool Use 有什么区别？

Function Calling 是 LLM 的能力——把自然语言转换成结构化的函数调用请求。LLM 本身不执行函数，只是告诉你"应该调用什么函数，参数是什么"。

MCP 是在 Function Calling 之上的协议层——它标准化了"函数在哪里、怎么调用、怎么发现"。

两者的关系：

用户输入 → LLM (Function Calling) → "需要调用 query_database"

                                           ↓

                                    MCP Protocol

                                           ↓

                                    MCP Server 执行

                                           ↓

                                    返回结果给 LLM

Function Calling 解决"决定做什么"，MCP 解决"怎么做到"。

MCP 的传输方式

MCP 支持两种主要的传输方式：

大部分云服务用 HTTP，本地脚本和自定义工具用 Stdio。

MCP 的代价

MCP 不是免费的午餐，它有明显的成本：

1. Token 消耗大

每个 MCP Server 都会占用上下文空间。每次对话开始，MCP Client 需要告诉 LLM "你有这些工具可用"，这些工具定义会消耗大量 Token。

连接多个 MCP Server 后，光是工具定义可能就占用了上下文窗口的很大一部分。社区观察到：

"We're seeing a lot of MCP developers even at enterprise build MCP servers that expose way too much, consuming the entire context window and leading to hallucination."

2. 需要维护连接

MCP Server 是持久连接的外部进程。Server 挂了、网络断了、认证过期了，都会影响 AI 的能力。

3. 安全风险

Anthropic 官方警告：

"Use third party MCP servers at your own risk - Anthropic has not verified the correctness or security of all these servers."

特别是能获取外部内容的 MCP Server（比如网页抓取），可能带来 prompt injection 风险。

MCP 的价值

尽管有这些代价，MCP 的价值在于标准化和可复用性：

• 一次实现，到处使用：同一个 GitHub MCP Server 可以在 Claude Desktop、Cursor、Windsurf 中使用


• 动态发现：AI 可以在运行时发现有哪些工具可用，而不是写死在代码里


• 供应商无关：不依赖特定的 LLM 提供商

Skill：上下文工程的渐进式公开

Skill 是什么

Skill（全称 Agent Skill）是 Anthropic 在 2025 年 10 月发布的特性。官方定义：

"Skills are organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks."

翻译一下：Skill 是一个文件夹，里面放着指令、脚本和资源，AI 会根据需要自动发现和加载。

Skill 在架构层级上和 MCP 不同。

用 Anthropic 的话说：

"Skills are at the prompt/knowledge layer, whereas MCP is at the integration layer."

Skill 是"提示/知识层"，MCP 是"集成层"。两者解决不同层面的问题。

Skill 的核心设计：渐进式信息公开

Skill 最精妙的设计是渐进式信息公开（Progressive Disclosure）。这是 Anthropic 在上下文工程（Context Engineering）领域的重要实践。

官方的比喻：

"Like a well-organized manual that starts with a table of contents, then specific chapters, and finally a detailed appendix."

就像一本组织良好的手册：先看目录，再翻到相关章节，最后查阅附录。

Skill 分三层加载：

flowchart TD

    subgraph L1["第 1 层：元数据（始终加载）"]

        A[Skill 名称 + 描述]

        B["约 100 tokens"]

    end



    subgraph L2["第 2 层：核心指令（按需加载）"]

        C[SKILL.md 完整内容]

        D["通常 < 5k tokens"]

    end



    subgraph L3["第 3+ 层：支持文件（深度按需）"]

        E[reference.md]

        F[scripts/helper.py]

        G[templates/...]

    end



    L1 --> |"Claude 判断相关"| L2

    L2 --> |"需要更多信息"| L3



    style L1 fill:#d4edda,stroke:#28a745

    style L2 fill:#fff3cd,stroke:#ffc107

    style L3 fill:#cce5ff,stroke:#0d6efd

这个设计的好处是什么？

传统方式（比如 MCP）在会话开始时就把所有信息加载到上下文。如果你有 10 个 MCP Server，每个暴露 5 个工具，那就是 50 个工具定义——可能消耗数千甚至上万 Token。

Skill 的渐进式加载让你可以有几十个 Skill，但同时只加载一两个。上下文效率大幅提升。

用官方的话说：

"This means that the amount of context that can be bundled int0 a skill is effectively unbounded."

理论上，单个 Skill 可以包含无限量的知识——因为只有需要的部分才会被加载。

上下文工程：Skill 背后的思想

Skill 是 Anthropic "上下文工程"（Context Engineering）理念的产物。官方对此有专门的阐述：

"At Anthropic, we view context engineering as the natural progression of prompt engineering. Prompt engineering refers to methods for writing and organizing LLM instructions for optimal outcomes. Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference."

简单说：

• Prompt Engineering：怎么写好提示词


• Context Engineering：怎么管理上下文窗口里的信息

LLM 的上下文窗口是有限的（即使是 200k 窗口，也会被大量信息撑爆）。Context Engineering 的核心问题是：在有限的窗口里，放什么信息能让 AI 表现最好？

Skill 的渐进式加载就是 Context Engineering 的具体实践——只加载当前任务需要的信息，让每一个 Token 都发挥最大价值。

Skill 的触发机制

Skill 是自动触发的，这是它和 Slash Command 的关键区别。

工作流程：

用户不需要显式调用。比如你有一个 code-review Skill，用户说"帮我 review 这段代码"，Claude 会自动匹配并加载。

Skill 的本质是什么？

技术上，Skill 是一个元工具（Meta-tool）：

"The Skill tool is a meta-tool that manages all skills. Traditional tools like Read, Bash, or Write execute discrete actions and return immediate results. Skills operate differently—rather than performing actions directly, they inject specialized instructions int0 the conversation history and dynamically modify Claude's execution environment."

Skill 不是执行具体动作，而是注入指令到对话历史中，动态修改 Claude 的执行环境。

Skill 的文件结构

一个标准的 Skill 长这样：

my-skill/

├── SKILL.md              # 必需：元数据 + 主要指令

├── reference.md          # 可选：详细参考文档

├── examples.md           # 可选：使用示例

├── scripts/

│   └── helper.py         # 可选：可执行脚本

└── templates/

    └── template.txt      # 可选：模板文件

SKILL.md 是核心，必须包含 YAML 格式的元数据：

---

name: code-review

description: >

  Review code for bugs, security issues, and style violations.

  Use when asked to review code, check for bugs, or audit PRs.

---



# Code Review Skill



## Instructions



When reviewing code, follow these steps:



1. First check for security vulnerabilities...

2. Then check for performance issues...

3. Finally check for code style...

关键字段：

• name：Skill 的唯一标识，小写字母 + 数字 + 连字符，最多 64 字符


• description：描述做什么、什么时候用，最多 1024 字符

description 的质量直接决定 Skill 能不能被正确触发。

Skill 的安全考虑

Skill 有一个潜在的安全问题：Prompt Injection。

研究人员发现：

"Although Agent Skills can be a very useful tool, they are fundamentally insecure since they enable trivially simple prompt injections. Researchers demonstrated how to hide malicious instructions in long Agent Skill files and referenced scripts to exfiltrate sensitive data."

因为 Skill 本质上是注入指令，恶意的 Skill 可以在长文件中隐藏恶意指令，窃取敏感数据。

应对措施：

---

name: safe-file-reader

description: Read and analyze files without making changes

allowed-tools: Read, Grep, Glob  # 只允许读操作

---

Skill 的平台支持

Agent Skills 目前支持：

• Claude.ai（Pro、Max、Team、Enterprise）


• Claude Code


• Claude Agent SDK


• Claude Developer Platform

需要注意的是，Skill 目前是 Anthropic 生态专属的，不像 MCP 是跨平台的开放协议。

MCP vs Skill：架构层级对比

现在我们可以从架构层级来理解两者的区别：

┌─────────────────────────────────────────────────────────┐

│                     用户请求                             │

└────────────────────────┬────────────────────────────────┘

                         ▼

┌─────────────────────────────────────────────────────────┐

│                  提示/知识层 (Skill)                     │

│                                                          │

│   Skill 注入专业知识和工作流程                           │

│   "怎么做某类任务"                                       │

└────────────────────────┬────────────────────────────────┘

                         ▼

┌─────────────────────────────────────────────────────────┐

│                    LLM 推理层                            │

│                                                          │

│   Claude / GPT / Gemini 等                              │

│   理解请求，决定需要什么工具                             │

└────────────────────────┬────────────────────────────────┘

                         ▼

┌─────────────────────────────────────────────────────────┐

│                  集成层 (MCP)                            │

│                                                          │

│   MCP 连接外部系统                                       │

│   "能访问什么工具和数据"                                 │

└────────────────────────┬────────────────────────────────┘

                         ▼

┌─────────────────────────────────────────────────────────┐

│                   外部世界                               │

│                                                          │

│   数据库、API、文件系统、第三方服务                      │

└─────────────────────────────────────────────────────────┘

Skill 在上层（知识层），MCP 在下层（集成层）。

两者不是替代关系，而是互补关系。你可以：

• 用 MCP 连接 GitHub


• 用 Skill 教 AI 如何按照团队规范做 Code Review

详细对比表

什么时候用 MCP，什么时候用 Skill

用 MCP 的场景

• 需要访问外部数据：数据库查询、API 调用、文件系统访问


• 需要操作外部系统：创建 GitHub Issue、发送 Slack 消息、执行 SQL


• 需要实时信息：监控系统状态、查看日志、搜索引擎结果


• 需要跨平台复用：同一个工具在 Claude Desktop、Cursor、其他支持 MCP 的应用中使用

用 Skill 的场景

• 重复性的工作流程：代码审查、文档生成、数据分析


• 公司内部规范：代码风格、提交规范、文档格式


• 需要多步骤的复杂任务：需要详细指导的专业任务


• 团队共享的最佳实践：标准化的操作流程


• Token 敏感场景：需要大量知识但不想一直占用上下文

结合使用

很多时候，两者是配合使用的：

用户："Review PR #456 并按照团队规范给出建议"



1. MCP (GitHub) 获取 PR 信息

        ↓

2. Skill (团队代码审查规范) 提供审查方法论

        ↓

3. Claude 按照 Skill 的指令分析代码

        ↓

4. MCP (GitHub) 提交评论

MCP 负责"能访问什么"，Skill 负责"怎么做"。

写好 Skill 的关键

Skill 能不能被正确触发，90% 取决于 description 写得好不好。

差的 description

description: Helps with data

太宽泛，Claude 不知道什么时候该用。

好的 description

description: >

  Analyze Excel spreadsheets, generate pivot tables, and create charts.

  Use when working with Excel files (.xlsx), spreadsheets, or tabular data analysis.

  Triggers on: "analyze spreadsheet", "create pivot table", "Excel chart"

好的 description 应该包含：

最佳实践

官方建议：

关于 Slash Command

文章标题是 MCP vs Skill，但很多人也会问到 Slash Command，简单说一下。

Slash Command 是最简单的扩展方式——本质上是存储的提示词，用户输入 /命令名 时注入到对话中。

Skill vs Slash Command 的关键区别是触发方式：

问自己一个问题：用户是否需要显式控制触发时机？

• 需要 → Slash Command


• 不需要，希望 AI 自动判断 → Skill

总结

MCP 和 Skill 是 AI Agent 扩展的两种不同哲学：

记住这句话：

MCP connects AI to data; Skills teach AI what to do with that data.

MCP 让 AI 能"碰到"数据，Skill 教 AI 怎么"处理"数据。

它们不是替代关系，而是互补关系。一个成熟的 AI Agent 系统，两者都需要。

参考资源

MCP 官方资源

• Model Context Protocol 官网 - 协议规范、快速入门、Server 开发指南


• MCP Specification - 完整的协议规范文档


• Introducing the Model Context Protocol - Anthropic 发布 MCP 的官方博客


• MCP GitHub Organization - 官方 SDK、示例 Server、参考实现


• Awesome MCP Servers - 社区维护的 MCP Server 列表

Skill 官方资源

• Claude Code Skills 文档 - Skills 的完整文档


• Building effective agents - Anthropic 关于 Agent 设计的研究博客


• Context Engineering Guide - 上下文工程官方指南，理解 Skill 设计哲学的关键

跨平台采用

• OpenAI adds support for MCP - OpenAI 宣布支持 MCP


• Google Gemini MCP Support - Google 宣布 Gemini 支持 MCP

延伸阅读

• Function Calling vs MCP - 理解两者区别


• Claude Code Documentation - Claude Code 完整文档


• Prompt Engineering Guide - 提示工程基础，Context Engineering 的前置知识

如果你觉得这篇文章有帮助，欢迎关注我的 GitHub，下面是我的一些开源项目：

Claude Code Skills（按需加载，意图自动识别，不浪费 token，介绍文章）：

• code-review-skill - 代码审查技能，覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则（详细介绍）


• 5-whys-skill - 5 Whys 根因分析，说"找根因"自动激活


• first-principles-skill - 第一性原理思考，适合架构设计和技术选型

全栈项目（适合学习现代技术栈）：

• prompt-vault - Prompt 管理器，用的都是最新的技术栈，适合用来学习了解最新的前端全栈开发范式：Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例，clone 下来配个免费 Supabase 就能跑


• chat_edit - 双模式 AI 应用（聊天+富文本编辑），Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB

你是不是也有这些困惑

看项目文档，各种名词扑面而来：

• 流程引擎（Flowable、Camunda）


• 工作流（Activiti）


• 规则引擎（Drools）


• 编排系统（LiteFlow）


• 表达式引擎（QLExpress、Aviator）


• DAG调度（Airflow、DolphinScheduler）


• 任务编排（Temporal、Conductor）


• BPMN、Saga、Event-Driven...

每个框架都说自己能解决问题，每个概念看起来都差不多。

新手一脸懵逼，老手也经常搞混。

干了20年，我也被这些东西搞晕过。今天不讲那些虚的，直接告诉你怎么选。

答案很简单：别管这些名词，问自己四个问题就够了。

忘掉那些名词，只问四个问题

看了一堆框架介绍还是不知道选哪个？正常，因为你在纠结概念。

别纠结了，概念都是虚的。问自己四个问题，立刻就清楚了。

问题1：你是要干活，还是改状态？

这是最关键的一个问题。搞清楚这个，一大半框架就排除了。

改状态是什么意思？

请假审批：

员工提交 → 主管看了说"行" → HR看了说"行" → 完成



整个过程：

- 没有计算

- 没有数据转换

- 没有调用外部系统

- 就是状态从 pending 变成 approved



这就是纯改状态。

干活是什么意思？

订单处理：

下单 → 扣库存 → 调支付接口 → 调物流接口 → 发货



整个过程：

- 要计算金额

- 要调用外部API

- 要处理数据

- 要执行业务逻辑



这就是干活。

判断标准：

• 改状态：就是让人点"同意"或"拒绝"，除了改个字段，啥也没干


• 干活：要计算、要调API、要处理数据

对应框架：

• 改状态 → BPMN系（Flowable、Camunda）


• 干活 → 继续往下判断

问题2：主要是人处理，还是机器执行？

人处理：

审批流程：

- 主管要看文档

- 主管要做判断

- 主管要点按钮

- 然后等下一个人



特点：大部分时间在等人

机器执行：

数据处理：

- 读数据库

- 清洗数据

- 转换格式

- 写入目标表



特点：机器自己跑，不用人管

对应框架：

• 人为主 → BPMN系（Flowable、Camunda）


• 机器为主 → 继续往下判断

问题3：是本地方法，还是跨系统调用？

本地方法：

营销规则：

- 判断用户是不是VIP

- 计算折扣

- 返回结果



都在一个应用里，不用调外部接口

跨系统调用：

订单流程：

- 调库存系统（HTTP）

- 调支付系统（HTTP）

- 调物流系统（HTTP）



要跨多个服务

对应框架：

• 本地 → 表达式系、脚本系（QLExpress、LiteFlow）


• 跨系统 → DAG系、服务编排系（Airflow、Temporal）

问题4：自己玩，还是要搞生态？

自己玩：

你的团队自己维护：

- 规则你们自己写

- 代码你们自己改

- 不需要外部开发者

搞生态：

做平台，让别人扩展：

- 客户可以上传插件

- 第三方可以写脚本

- 需要沙箱隔离

对应技术：

• 自己玩 → 表达式 + 代码（QLExpress、Aviator）


• 搞生态 → Groovy脚本、插件机制

那些让人头疼的框架，到底是干什么的

四个问题问完，你大概知道方向了。现在看看具体框架都是什么情况。

不用全看，只看和你匹配的那一类就行。

BPMN系：Flowable、Camunda、Activiti

适合场景：

• 纯人工审批流程


• 需要流程图可视化


• 需要历史记录追溯


• 大公司、强合规要求

典型例子：

• 请假审批


• 报销审批


• 合同审批


• 采购流程

核心特点：

• 本质就是改状态


• 大部分时间在等人


• 业务价值为0（只是流程管理）


• 技术难度不高（就是状态机）

什么时候用：

• 大公司（100+人），有几十个审批流程要管理


• 金融、政府等强合规行业


• 需要标准化流程管理

什么时候别用：

• 小公司（别用，钉钉审批就够了）


• 没有复杂审批需求（自己写100行代码搞定）


• 为了"企业级"而用（过度设计）

DAG系：Airflow、DolphinScheduler、Prefect

适合场景：

• 数据处理任务


• 离线批处理


• 定时调度


• 任务有依赖关系

典型例子：

• 数据ETL


• 报表生成


• 数据清洗


• 机器学习Pipeline

核心特点：

• 纯机器执行


• 长时间运行（小时、天级）


• 任务之间有依赖（A完成才能B）


• 需要调度和监控

什么时候用：

• 数据团队做离线处理


• 有复杂的任务依赖关系


• 需要定时调度（每天、每周）

什么时候别用：

• 实时性要求高的（秒级响应）


• 简单的定时任务（用Cron就够了）


• 没有依赖关系的任务

表达式/脚本系：QLExpress、Aviator、LiteFlow、Groovy

适合场景：

• 规则计算


• 业务流程编排


• 本地方法调用


• 需要动态配置

典型例子：

• 营销活动规则（满减、折扣）


• 风控规则（黑名单、评分）


• 订单流程（本地编排）


• 积分计算

QLExpress / Aviator（表达式）：

• 优点：性能好、类Java语法、团队容易上手


• 缺点：功能受限、只能简单计算


• 适合：自己团队玩、简单规则

Groovy（脚本）：

• 优点：功能完整、可以调复杂API


• 缺点：性能差、调试难、类型不安全


• 适合：要搞插件生态、客户自定义逻辑

LiteFlow（编排）：

• 优点：可视化编排、组件复用


• 缺点：学习成本、维护成本


• 适合：流程确实复杂、经常变化

什么时候用：

• 规则经常变（不想每次改代码发版）


• 流程需要配置化


• 有一定复杂度（10+个分支）

什么时候别用：

• 简单的if-else（直接写代码）


• 流程固定不变（没必要配置化）


• 为了"灵活"而牺牲性能

服务编排系：Temporal、Cadence、Conductor

适合场景：

• 微服务编排


• 分布式事务


• 长时间运行的业务流程


• 需要补偿机制

典型例子：

• 订单流程（支付 → 发货 → 签收）


• 旅游预订（机票 + 酒店 + 门票）


• 跨系统流程


• Saga模式

核心特点：

• 支持长时间运行（天级）


• 支持失败重试


• 支持补偿逻辑


• 状态持久化

什么时候用：

• 微服务架构，需要编排多个服务


• 需要分布式事务


• 流程可能运行很久（几小时、几天）

什么时候别用：

• 单体应用（没有跨服务需求）


• 简单的API调用（直接用HTTP就行）


• 实时性要求极高的（毫秒级）

懒得看？直接照这个选

如果你嫌上面内容太多，直接看这个决策树。

跟着问题一步步走，到底了就知道该用什么。

开始

  ↓

主要是人审批吗？

  ↓ 是

  用 Flowable/Camunda（大公司）或钉钉审批（小公司）

  

  ↓ 否

是长时间运行的任务吗（>10分钟）？

  ↓ 是

  用 Airflow/DolphinScheduler

  

  ↓ 否

需要跨系统调用吗？

  ↓ 是

  用 Temporal/Conductor（微服务）或 Airflow（数据处理）

  

  ↓ 否

逻辑很复杂吗（>10个分支）？

  ↓ 是

  用 LiteFlow（编排）或 QLExpress（规则）

  

  ↓ 否

需要频繁修改规则吗？

  ↓ 是

  用 QLExpress/Aviator

  

  ↓ 否

直接写代码！

具体场景怎么选

理论说完了，看几个实际例子。看看你的场景和哪个像。

场景1：请假审批

特征：

• 纯人工审批


• 状态流转


• 需要历史记录

选型：

• 小公司：钉钉/企业微信审批


• 大公司：Flowable/Camunda


• 自己开发：状态机 + 数据库

场景2：电商订单流程

特征：

• 要调支付、库存、物流接口


• 有失败重试和补偿


• 短事务（分钟级）

选型：

• 复杂场景：Temporal/Cadence


• 简单场景：LiteFlow + 消息队列


• 最简单：直接写代码 + 状态机

场景3：数据ETL

特征：

• 纯机器执行


• 长时间运行


• 任务有依赖

选型：

• 标准方案：Airflow/DolphinScheduler


• 简单场景：XXL-Job

场景4：营销活动规则

特征：

• 规则计算


• 经常变化


• 本地方法

选型：

• 简单规则：QLExpress/Aviator


• 复杂规则：Drools


• 有编排需求：LiteFlow

很多人踩过的坑

说几个常见的错误，别重复踩坑。

误区1：追求"企业级架构"

错误做法：

20人的创业公司，上了Flowable、Camunda、Airflow一整套



正确做法：

能用100行代码解决就别上框架

误区2：为了灵活性而牺牲性能

错误做法：

所有逻辑都用Groovy脚本，方便修改



正确做法：

核心逻辑用Java写，只把经常变的部分配置化

误区3：过度抽象

错误做法：

3个简单流程，非要搞个"流程引擎"



正确做法：

3个流程就3个方法，直接写代码

误区4：混淆概念

错误理解：

"我需要流程编排，所以要用Flowable"



正确理解：

先搞清楚你要干活还是改状态

是人审批还是机器执行

几句大实话

最后说几句掏心窝的话。

1. 先用最简单的方案

遇到问题：

第一反应不是"上框架"

而是"能不能写100行代码搞定"



90%的情况，100行代码就够了

2. 遇到瓶颈再优化

流程很乱了 → 重构代码

改动很频繁 → 考虑配置化

管理不过来 → 考虑框架



别提前优化

3. 根据团队规模选择

小团队（<20人）：

- 能不用框架就不用

- 钉钉审批、Cron、直接写代码



中等团队（20-100人）：

- 流程<10个：自己写

- 流程>10个：考虑轻量级框架



大团队（>100人）：

- 需要标准化管理

- 可以考虑成熟框架

4. 看业务特点

强合规（金融、政府）：

- 必须用标准化工具

- Flowable是选择之一



数据密集：

- Airflow是标准方案



微服务架构：

- Temporal值得考虑



简单CRUD：

- 别折腾，写代码

说到底，就这么点事

看完还觉得复杂？那就记住这四个问题：

四个问题问完，基本就知道该用什么了。

那些"企业级"、"先进架构"、"灵活扩展"的词，都是包装。

看透本质，别被忽悠。

能用100行代码解决的，就别上框架。

技术是为业务服务的，不是为了炫技。

务实点，别整那些虚的。

就这样。

面试导航 是一个专注于前、后端技术学习和面试准备的 免费 学习平台，提供系统化的技术栈学习，深入讲解每个知识点的核心原理，帮助开发者构建全面的技术体系。平台还收录了大量真实的校招与社招面经，帮助你快速掌握面试技巧，提升求职竞争力。如果你想加入我们的交流群，欢迎通过微信联系：yunmz777。

在需要服务器实时向浏览器推送数据的场景中，很多人第一反应是使用 WebSocket，但其实还有一种更轻量、更简单的解决方案 —— SSE（Server-Sent Events）。它天生适合“服务器单向推送”，而且浏览器原生支持、无需额外协议、写起来极其简单。

本文将从原理、协议、代码、对比、性能、安全等多个方面，帮你系统了解 SSE 的底层机制与实际应用。

🧠 一、什么是 SSE？

SSE，全称 Server-Sent Events，是 HTML5 提出的标准之一，用于建立一种 客户端到服务器的持久连接，允许服务器在数据更新时，主动将事件推送到客户端。

通俗点讲，它就像是：

浏览器发起了一个请求，服务器就打开一个“水管”，源源不断地往客户端输送数据流，直到你手动关闭它。

它基于标准的 HTTP 协议，与传统请求-响应的“短连接”模式不同，SSE 是长连接，并且保持活跃，类似于“实时通知通道”。

🛠️ 二、SSE 的通信机制与协议细节

✅ 客户端：使用 EventSource 建立连接

const sse = new EventSource("/events");



sse.onmessage = (event) => {

  console.log("新消息：", event.data);

};

EventSource 是浏览器自带的，直接用就行，不用装库。它会自动处理连接、断线重连这些问题，基本不需要你操心，消息来了就能收到。

原生 EventSource 的使用限制

虽然原生的 EventSource 对象很方便，但也存在很多的限制，它只能发送 GET 请求，不支持设置请求方法，也不能附带请求体。

你不能通过 EventSource 设置如 Authorization、token 等自定义请求头用于鉴权。

例如，下面这样是不被支持的：

const sse = new EventSource("/events", {

  headers: {

    Authorization: "Bearer xxx",

  },

});

这在 fetch 里没问题，但在 EventSource 里完全不支持。直接报错，浏览器压根不给你设置 headers。

EventSource 虽然支持跨域，但得服务器配合设置 CORS，而且还不能用 withCredentials。换句话说，你不能让它自动带上 cookie，那些基于 cookie 登录的服务就麻烦了。

如果你需要传 token 或做鉴权，可以使用查询参数传 token，比如这样：

const token = "abc123";

const sse = new EventSource(`/events?token=${token}`);

✅ 服务器：响应格式必须为 text/event-stream

服务器需要返回特定格式的数据流，并设置以下 HTTP 响应头：

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

如下图所示：

然后每条消息遵循下面的格式：

data: Hello from server

id: 1001

event: message

如下图所示：

在上面的内容中，主要有以下解释，如下表格所示：

🔄 三、SSE vs WebSocket vs 轮询，对比总结

🚀 四：如何在 NextJs 中实现

NextJS 作为一个现代化的 React 框架，非常适合实现 SSE。下面我们将通过一个完整的实例来展示如何在 NextJS 应用中实现服务器发送事件。

前端代码如下：

"use client";



import React, { useState, useEffect, useRef } from "react";



export default function SSEDemo() {

  const [sseData, setSseData] = useState<{

    time?: string;

    value?: string;

    message?: string;

    error?: string;

  } | null>(null);

  const [connected, setConnected] = useState(false);

  const [reconnecting, setReconnecting] = useState(false);

  const [reconnectCount, setReconnectCount] = useState(0);

  const eventSourceRef = useRef<EventSource | null>(null);

  const reconnectTimeoutRef = useRef<NodeJS.Timeout | null>(null);



  // 建立SSE连接

  const connectSSE = () => {

    // 关闭任何现有连接

    if (eventSourceRef.current) {

      eventSourceRef.current.close();

    }



    // 清除任何挂起的重连计时器

    if (reconnectTimeoutRef.current) {

      clearTimeout(reconnectTimeoutRef.current);

    }



    try {

      setReconnecting(true);



      // 添加时间戳防止缓存

      const eventSource = new EventSource(`/api/sse?t=${Date.now()}`);

      eventSourceRef.current = eventSource;



      eventSource.onopen = () => {

        setConnected(true);

        setReconnecting(false);

        setReconnectCount(0);

        console.log("SSE连接已建立");

      };



      eventSource.onmessage = (event) => {

        try {

          const data = JSON.parse(event.data);

          setSseData(data);

        } catch (error) {

          console.error("解析SSE数据失败:", error);

        }

      };



      eventSource.onerror = (error) => {

        console.error("SSE连接错误:", error);

        setConnected(false);

        eventSource.close();



        // 增加重连次数

        setReconnectCount((prev) => prev + 1);



        // 随着失败次数增加，增加重连间隔（指数退避策略）

        const reconnectDelay = Math.min(

          30000,

          1000 * Math.pow(2, Math.min(reconnectCount, 5))

        );



        setReconnecting(true);

        setSseData((prev) => ({

          ...prev,

          message: `连接失败，${reconnectDelay / 1000}秒后重试...`,

        }));



        // 尝试重新连接

        reconnectTimeoutRef.current = setTimeout(() => {

          connectSSE();

        }, reconnectDelay);

      };

    } catch (error) {

      console.error("创建SSE连接失败:", error);

      setConnected(false);

      setReconnecting(true);



      // 5秒后重试

      reconnectTimeoutRef.current = setTimeout(() => {

        connectSSE();

      }, 5000);

    }

  };



  useEffect(() => {

    connectSSE();



    // 定期检查连接是否健康

    const healthCheck = setInterval(() => {

      if (eventSourceRef.current && !connected) {

        // 如果存在连接但状态是未连接，尝试重新连接

        connectSSE();

      }

    }, 30000);



    // 清理函数

    return () => {

      if (eventSourceRef.current) {

        eventSourceRef.current.close();

      }

      if (reconnectTimeoutRef.current) {

        clearTimeout(reconnectTimeoutRef.current);

      }

      clearInterval(healthCheck);

    };

  }, []);



  return (

    <div className="min-h-screen bg-gradient-to-b from-slate-900 to-slate-800 text-white flex flex-col items-center justify-center p-4">

      <div className="w-full max-w-md bg-slate-800 rounded-xl shadow-2xl overflow-hidden">

        <div className="p-6 border-b border-slate-700">

          <h1 className="text-3xl font-bold text-center text-blue-400">

            SSE 演示

          </h1>

          <div className="mt-2 flex items-center justify-center">

            <div

              className={`h-3 w-3 rounded-full mr-2 ${

                connected

                  ? "bg-green-500"

                  : reconnecting

                  ? "bg-yellow-500 animate-pulse"

                  : "bg-red-500"

              }`}

            ></div>

            <p className="text-sm text-slate-300">

              {connected

                ? "已连接到服务器"

                : reconnecting

                ? `正在重新连接 (尝试 ${reconnectCount})`

                : "连接断开"}

            </p>

          </div>



          {!connected && (

            <button

              onClick={() => connectSSE()}

              className="mt-3 px-3 py-1 bg-blue-600 text-sm text-white rounded-md mx-auto block hover:bg-blue-700"

            >

              手动重连

            </button>

          )}

        </div>



        {sseData && (

          <div className="p-6">

            {sseData.error ? (

              <div className="rounded-lg bg-red-900/30 p-4 mb-4 text-center border border-red-800">

                <p className="text-lg text-red-300">{sseData.error}</p>

              </div>

            ) : sseData.message ? (

              <div className="rounded-lg bg-slate-700 p-4 mb-4 text-center">

                <p className="text-lg text-blue-300">{sseData.message}</p>

              </div>

            ) : (

              <div className="space-y-4">

                <div className="flex justify-between items-center">

                  <span className="text-slate-400">时间:</span>

                  <span className="font-mono bg-slate-700 px-3 py-1 rounded-md text-blue-300">

                    {sseData.time &&

                      new Date(sseData.time).toLocaleTimeString()}

                  </span>

                </div>

                <div className="flex justify-between items-center">

                  <span className="text-slate-400">随机值:</span>

                  <span className="font-mono bg-slate-700 px-3 py-1 rounded-md text-green-300">

                    {sseData.value}

                  </span>

                </div>

              </div>

            )}

          </div>

        )}



        {!sseData && (

          <div className="p-6 text-center text-slate-400">

            <p>等待数据中...</p>

            <div className="mt-4 flex justify-center">

              <div className="animate-spin rounded-full h-8 w-8 border-t-2 border-b-2 border-blue-400"></div>

            </div>

          </div>

        )}

      </div>

    </div>

  );

}

在上面的代码中，我们用的是浏览器的原生 EventSource，加了个时间戳 t=${Date.now()} 是为了防止缓存，确保每次都是新的连接。

然后我们监听三个事件：

当连接出错时，我们做了这些事：

而且页面上也有提示「正在重连」和「手动重连」的按钮，体验很人性化。

接下来我们看看后端代码，如下：

export async function GET() {

  // 标记连接是否仍然有效，

  let connectionClosed = false;



  // 使用Next.js的流式响应处理

  return new Response(

    new ReadableStream({

      start(controller) {

        const encoder = new TextEncoder();



        // 监测响应对象是否被关闭

        const abortController = new AbortController();

        const signal = abortController.signal;



        signal.addEventListener("abort", () => {

          connectionClosed = true;

          cleanup();

        });



        // 安全发送数据函数

        const safeEnqueue = (data: string) => {

          if (connectionClosed) return;

          try {

            controller.enqueue(encoder.encode(data));

          } catch (error) {

            console.error("SSE发送错误:", error);

            connectionClosed = true;

            cleanup();

          }

        };



        // 发送初始数据

        safeEnqueue(`data: ${JSON.stringify({ message: "连接已建立" })}\n\n`);



        // 定义interval引用

        let heartbeatInterval: NodeJS.Timeout | null = null;

        let dataInterval: NodeJS.Timeout | null = null;



        // 清理所有资源

        const cleanup = () => {

          if (heartbeatInterval) clearInterval(heartbeatInterval);

          if (dataInterval) clearInterval(dataInterval);



          // 尝试安全关闭控制器

          try {

            if (!connectionClosed) {

              controller.close();

            }

          } catch (e) {

            // 忽略关闭时的错误

          }

        };



        // 设置10秒的心跳间隔，避免连接超时

        heartbeatInterval = setInterval(() => {

          if (connectionClosed) {

            cleanup();

            return;

          }

          safeEnqueue(": heartbeat\n\n");

        }, 10000);



        // 每秒发送一次数据

        dataInterval = setInterval(() => {

          if (connectionClosed) {

            cleanup();

            return;

          }



          try {

            const data = {

              time: new Date().toISOString(),

              value: Math.random().toFixed(3),

            };

            safeEnqueue(`data: ${JSON.stringify(data)}\n\n`);

          } catch (error) {

            console.error("数据生成错误:", error);

            connectionClosed = true;

            cleanup();

          }

        }, 1000);



        // 60秒后自动关闭连接（可根据需要调整）

        setTimeout(() => {

          // 只有当连接仍然活跃时才发送消息和关闭

          if (!connectionClosed) {

            try {

              safeEnqueue(

                `data: ${JSON.stringify({

                  message: "连接即将关闭，请刷新页面重新连接",

                })}\n\n`

              );

              connectionClosed = true;

              cleanup();

            } catch (e) {

              // 忽略关闭时的错误

            }

          }

        }, 60000);

      },

      cancel() {

        // 当流被取消时调用

        connectionClosed = true;

      },

    }),

    {

      headers: {

        "Content-Type": "text/event-stream",

        "Cache-Control": "no-cache, no-transform",

        Connection: "keep-alive",

        "Access-Control-Allow-Origin": "*",

        "X-Accel-Buffering": "no", // 适用于某些代理服务器如Nginx

      },

    }

  );

}

这段代码是 Next.js 后端 API 路由，用来实现 SSE（Server-Sent Events）长连接。我们使用了 ReadableStream 创建一个持续向前端推送数据的响应流，并配合 AbortSignal 检测连接是否被关闭：

return new Response(new ReadableStream({ start(controller) { ... } }), { headers: {...} });

一开始，服务器通过 safeEnqueue 安全地向客户端发送一条欢迎消息：

safeEnqueue(`data: ${JSON.stringify({ message: "连接已建立" })}\n\n`);

随后每秒生成一条数据（当前时间和随机值）推送给前端，并通过 setInterval 定时发送：

const data = {

  time: new Date().toISOString(),

  value: Math.random().toFixed(3),

};

safeEnqueue(`data: ${JSON.stringify(data)}\n\n`);

为了保持连接活跃，避免浏览器或代理中断连接，我们每 10 秒发送一次心跳包（以冒号开头的注释）：

safeEnqueue(": heartbeat\n\n");

还加了一个自动关闭机制——60 秒后主动断开连接并提示前端刷新：

safeEnqueue(

  `data: ${JSON.stringify({ message: "连接即将关闭，请刷新页面重新连接" })}\n\n`

);

整个数据发送过程都包裹在 safeEnqueue 中，确保连接断开时能安全终止，并调用 cleanup() 清理资源。响应头中我们指定了 text/event-stream，关闭了缓存，并设置了必要的长连接参数：

headers: {

  "Content-Type": "text/event-stream",

  "Cache-Control": "no-cache, no-transform",

  Connection: "keep-alive",

  "Access-Control-Allow-Origin": "*",

  "X-Accel-Buffering": "no"

}

通过这种方式，服务端可以稳定地向客户端发送实时数据，同时具备自动断开、心跳维持、错误处理等健壮性，是非常实用的 SSE 实践方案。

最终结果如下图所示：

成功实现。

总结

SSE（Server-Sent Events）是一种基于 HTTP 的 服务器向客户端单向推送数据的机制，适用于需要持续更新前端状态的场景。除了浏览器原生支持的 EventSource，也可以通过 fetch + ReadableStream 或框架内置流式处理（如 Next.js API Route、Node.js Response Stream）来实现，适配更复杂或自定义需求。相比 WebSocket，SSE 实现更简单，自动断线重连、无需维护双向协议，非常适合实时消息通知、进度条更新、在线人数统计、系统日志流、IoT 设备状态推送等。它特别适合“只要服务器推就好”的场景，无需双向通信时是高效选择。

在大模型狂飙突进的今天，高质量、结构化的数据已成为决定 AI 能力的核心基建。而现实中，海量知识却沉睡在PDF、扫描件、报告等非结构化文档中。

如何将这座富矿高效、精准地转化为大模型可理解、可训练的数据燃料，是整个产业面临的关键瓶颈。

OCR（光学字符识别）技术正是打通这一瓶颈的数据管道。但传统OCR主要停留在「字符识别」层面，面对包含图表、公式、代码以及复杂版式的文档时，往往会产出混乱的文本流，难以支撑后续理解、检索等等需求。

因此，在大模型时代，这一能力已远远不够。一个真正可用的文档解析方案，必须提供端到端的文档智能解析能力：不仅「看得准」，更要「懂得清」。

它需要在识别文本的同时，理解文档的语义结构和版式逻辑，将原始文档精准还原为包含标题、段落、表格、图表描述、公式 LaTeX、代码块等语义信息的标准化表示形式（如 Markdown / JSON）。

只有当非结构化文档被转化为高质量、可直接消费的结构化数据，才能真正成为大模型训练、知识库构建、RAG 检索与智能问答中的可靠数据原料，从而发挥它应有的价值。

今天，这个关键的「数据管道」迎来了它里程碑式产品化升级——PaddleOCR 官网（http://www.paddleocr.com）正式版上线了！

这不仅是其强大开源能力的直观展现，更通过丝滑的体验与海量API，将文档结构化能力推向了普惠化应用。

熟悉我的老粉都知道，过去如果我要推荐 OCR 或文档解析工具，基本只会提到 PaddleOCR。原因很简单：我希望为大家提供一条最高效、最直接的“生产力路径”，而不是让大家在众多项目中反复试错。

这不仅是我的推荐逻辑，也是各大模型厂商在开源选型时的共识——PaddleOCR 几乎是文档解析领域唯一被广泛引用的开源方案。

今年 10 月 17 日 PaddleOCR-VL 刚刚发布，仅用 16 小时就登顶 HuggingFace Trending 全球榜首。

短短两个月内，项目的 Star 数从 57k 飙升至接近 67k。要知道，一个开源项目在五年之后还能保持这样的增长速度，背后一定是它切中了真实且迫切的用户需求。

01、关键特性：三大模型，覆盖全场景文档解析

打开官网，你会看到三个核心入口：GitHub 开源地址、MCP 接口、API 接口。下方支持直接上传图像或 PDF，体验 PaddleOCR 的三大模型方案：

• PP-OCRv5：轻量级 OCR，适合纯文本提取


• PP-StructureV3：基于pipeline架构的文档解析，支持印章、表格、标题等还原，零幻觉


• PaddleOCR-VL（默认）：基于视觉-语言模型的文档解析，支持图文、公式、代码等多模态解析，当前全球最高精度

如果你还不清楚这些模型能力的区别，PaddleOCR 官方文档（http://www.paddleocr.ai）提供了清晰的说明，支持搜索与评论，非常友好。

我这里以 PaddleOCR-VL 为例，上传了一篇 DeepSeek-R1 的论文 PDF。

几秒后，解析结果清晰呈现：不管是文字、图像、代码、表格还是公式，PaddleOCR都能精准还原，相关内容，可以左右一一对应。

在右侧，你也可以复制所有的解析结果，也可以复制其中的某一个block的结果，还可以基于某一个block进行内容纠正。下边是一些关键场景的可视化。

·文字场景

一级标题、二级标题、正文层次分明，还原精准。

·图像/图表场景

支持图表转表格，对科研与数据分析工作者极其友好。关闭图表识别功能：

打开图表识别功能：

这项功能极其实用，能够将图表等非结构化数据转换为结构化表格，对于科研人员以及日常需要处理图表数据的工作者而言，是一项极具价值的工具。

·代码场景

代码区域被转换为等宽字体，代码的格式与内嵌公式保留完整，恢复完美。

·表格场景

合并单元格也能准确预测，精准还原表格中的各项指标。点击“复制”可直接粘贴至 Excel，格式无损。

此外，在表格应用场景中，我还发现了一个小惊喜：点击右侧下方表格区块的复制按钮后，可以将表格内容无损地粘贴到Excel中，原有格式能够完整保留。这个功能对我日常整理数据非常有帮助，没想到能够如此完美地实现。

不过，官方似乎并未特别宣传这项小功能，看来还有许多实用细节有待用户进一步发掘。

·公式场景 

LaTeX 格式输出，右侧实时渲染，复杂公式也无错漏。

公式内容会被自动识别并转换为LaTeX格式的代码，随后在右侧的Markdown区域被正确渲染。经过对比验证，即使是较为复杂的公式也能够准确无误地显示，未发现任何错误。

·更多功能

此外，官网还支持批量上传（最多 20 个文件），并提供了超参数设置面板，除了默认的结果，还有一个设置超参数的按钮，用户可根据需求设置很多超参数，关于超参数的解释，也在旁边隐藏的部分有解释。

比如上边的图表识别的功能，我就是打开了这个超参数中的图表识别的开关，灵活度很高。

02

API 调用：数据基建的“普惠管道”

PaddleOCR官网首页已直接提供了 API 和 MCP 的调用示例，点击就可以有对应的弹窗，亲测带上token，复制可以跑。这里以 API 为例，MCP类似。

基础跑通三步走：

1. 点击首页的API：

2. 复制代码到本地

在本地电脑新建一个名为 test.py 的文件，并将复制的代码粘贴进去（此时你的账号 token 也会被自动复制）。然后，在代码中的 file_path 参数填写你要预测的文件名。这里需要注意的是：如果是 PDF 文件，fileType 应设置为 0；如果是图像文件，fileType 则需要设置为 1。

3. 运行代码

大约在20多秒可以返回一个21页的PDF结果，包含了每一页的Markdown的结果、对应的插图等。基本上每秒一页，速度还不错。本地可视化如图所示，和网页端完全一致。

进阶玩法三步走：

进一步体验PaddleOCR官网，会发现一些我认为非常重要的细节。

1. API和效果联动

这次 PaddleOCR 官网的一个重要变化，是前端整体把体验优化得非常友好了，不再只是“展示效果”，而是围绕 参数配置 → 效果验证 → API 接入 这条完整路径来设计。

在网页端，你可以直接调整解析参数，比如是否开启图表识别、是否需要方向矫正、不同结构化策略等，每一次参数变化，解析结果都会即时刷新返回。图像或 PDF 的结构化结果几乎是秒级可见，非常适合快速对比不同参数组合下的效果差异，而不是靠猜。

更关键的是，这些在网页端调过、验证过的参数，并不会停留在「试用层」。当你确认某一套配置满足你的业务需求后，可以直接一键复制对应的 API 调用代码，包括参数、模型类型和调用方式，拿到本地或直接接入业务系统即可使用。

整个过程非常顺滑：

你不需要先搭环境、不需要翻文档对着字段一个一个找参数含义，先在网页上把效果跑通，再把同一套配置“原封不动”搬进工程里。哪怕完全没有本地部署过，也可以先把解析效果看清楚、想明白，再决定是否以及如何在真实业务中使用。

一句话总结就是：

不用写一行代码，也能把PaddleOCR的能力验证到位；一旦要上线，代码已经帮你准备好了。

2.更多的 API 调用

在 API 文档页有一行关键说明：“每位用户每日对同一模型的解析上限为 3000 页，超出会返回 429 错误。如需更高额度，可通过问卷申请白名单。”

🔗申请链接为：paddle.wjx.cn/vm/mePnNLR.…

我填写了问卷中四个常规问题留下联系方式后，很快就有官方人员联系我，了解使用场景后直接开通了白名单。随后我测试了约 1 万份 PDF（共 3 万多页），开了一个后台的访问服务的进程挂机运行一夜，第二天一早，全部解析成功。这意味着，现阶段个人、团队或初创企业完全可以借助此额度，启动大规模的数据清洗与知识库构建工作，成本几乎为零。

3.不容错过的MCP

作为 AI 时代的 Type-C 接口，MCP 正逐渐成为各类 AI 产品的基础能力配置。PaddleOCR 官网也提供了开箱即用的 MCP server：只需复制官网给出的配置示例，并在 MCP host 应用中完成简单配置，即可让大模型直接调用 PaddleOCR 的文字识别与文档解析能力。

我也在 Cherry Studio 里试了试效果。花了不到一分钟复制粘贴 MCP 配置，然后使用 PaddleOCR 官网提供的 PP-OCRv5 MCP server 来识别图像中的酒店名称：

03、项目相关链接

官网虽已足够强大，但如果你有私有化部署需求，仍可基于开源项目自行部署。

·PaddleOCR GitHub：https://github.com/PaddlePaddle/PaddleOCR·官方文档：https://www.paddleocr.ai·Hugging Face 模型：https://huggingface.co/PaddlePaddle

PaddleOCR 再一次没有让人失望。从开源项目到产品化官网，从模型迭代到这波 API 的开放，它正在把文档智能从“技术能力”推向“普及工具”。大模型时代，数据是石油，而 OCR 则是开采与提炼的核心装备。PaddleOCR 这一次的升级，不仅提升了开采效率，还让更多人用上了这把利器。

期待大家亲自体验，也欢迎在评论区分享你的使用场景与发现。

Docker 和 K8s 的核心概念，用"快照"这个比喻就够了

前几天让同事帮忙部署服务，顺嘴问了句"Docker 和 K8s 到底是啥"。

其实这俩概念我以前看过，知道是"打包完整环境、到处运行"，但一直停留在似懂非懂的状态。镜像、容器、Pod、集群、节点……这些词都见过，就是串不起来。

同事给我讲了一个非常直观的比喻，一下就通了：

镜像：一个打包好的系统快照

Docker 镜像可以理解成一个系统快照，里面包含了：

• 操作系统（比如 Debian、Alpine）


• 运行时环境（比如 Python 3.11、Node 20）


• 所有依赖包


• 你的代码


• 配置文件

这个快照是静态的、只读的，就像一张光盘——刻好了就不会变。

容器：运行起来的快照

容器就是把镜像跑起来。

镜像（静态快照） --docker run--> 容器（运行中的进程）

容器是动态的、可写的，可以往里面写文件、改配置。但一旦容器销毁，这些改动就没了（除非你挂载了外部存储）。

一个镜像可以同时跑多个容器，就像一张光盘可以装到多台电脑上。

Dockerfile 和 docker-compose

搞清楚镜像和容器的关系后，这两个东西就好理解了：

• Dockerfile：定义如何构建镜像的配方


• docker-compose：定义如何运行一组容器

flowchart LR

    A["Dockerfile<br/>(配方)"] -->|docker build| B["Image<br/>(镜像/快照)"]

    B -->|docker run<br/>docker-compose up| C["Container<br/>(容器/运行态)"]

举个例子，你写了个 Python 服务：

# Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD ["python", "main.py"]

这个 Dockerfile 就是一份配方，告诉 Docker：

执行 docker build 就会按这个配方生成一个镜像。

为什么说"到处运行"

Docker 的核心价值就是解决"我这能跑，你那跑不了"的问题。

以前部署服务，你得操心：服务器是什么系统？装的什么版本的 Python？依赖库版本对不对？环境变量配了没？

现在有了 Docker，这些都打包进镜像了。不管你的服务器是 Ubuntu、CentOS 还是 Debian，只要装了 Docker，同一个镜像都能跑出一样的结果。

Pod：K8s 调度的最小单元

到了 Kubernetes 这一层，又多了一个概念：Pod。

Pod 是 K8s 定义的概念，是集群调度的最小单元。一个 Pod 里面可以有一个或多个容器。

你可能会问：为什么不直接调度容器，还要多一层 Pod？

因为有些场景下，几个容器需要紧密配合。比如一个主服务容器 + 一个日志收集容器，它们需要：

• 共享网络（用 localhost 通信）


• 共享存储（访问同一个目录）


• 一起启动、一起销毁

把它们放在一个 Pod 里，K8s 就会把它们调度到同一台机器上，共享资源。

不过大多数情况下，一个 Pod 就放一个容器。微服务架构下，每个服务就是一个 Pod：

flowchart TB

    subgraph Cluster["K8s 集群"]

        subgraph Node1["节点 1"]

            PodA["Pod A<br/>用户服务"]

            PodB["Pod B<br/>订单服务"]

        end

        subgraph Node2["节点 2"]

            PodC["Pod C<br/>支付服务"]

            PodD["Pod D<br/>网关服务"]

        end

    end

K8s 干的事情

K8s 负责管理这些 Pod：

• 调度：决定 Pod 跑在哪个节点上


• 扩缩容：流量大了自动多启几个 Pod，流量小了缩回去


• 自愈：Pod 挂了自动重启


• 网络：打通各个 Pod 之间的通信


• 存储：管理持久化存储

说白了，Docker 解决的是"打包和运行"的问题，K8s 解决的是"大规模部署和管理"的问题。

一台机器跑几个容器，手动管理就行。但当你有几十台机器、几百个容器的时候，就需要 K8s 这样的编排工具来帮你自动化处理。

Dockerfile → Image → Container → Pod → Node → Cluster

   配方       快照     运行态     调度单元   机器    集群

概念不难，难的是实际操作中的各种坑。但只要这个基础模型搞清楚了，遇到问题知道往哪个层面去排查就行。

如果你觉得这篇文章有帮助，欢迎关注我的 GitHub，下面是我的一些开源项目：

Claude Code Skills（按需加载，意图自动识别，不浪费 token，介绍文章）：

• code-review-skill - 代码审查技能，覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则（详细介绍）


• 5-whys-skill - 5 Whys 根因分析，说"找根因"自动激活


• first-principles-skill - 第一性原理思考，适合架构设计和技术选型

qwen/gemini/claude - cli 原理学习网站：

• coding-cli-guide（学习网站）- 学习 qwen-cli 时整理的笔记，40+ 交互式动画演示 AI CLI 内部机制
  

全栈项目（适合学习现代技术栈）：

• prompt-vault - Prompt 管理器，用的都是最新的技术栈，适合用来学习了解最新的前端全栈开发范式：Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例，clone 下来配个免费 Supabase 就能跑


• chat_edit - 双模式 AI 应用（聊天+富文本编辑），Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB

下面是我在nginx使用过程中发现的几个问题，分享出来大家一起熟悉一下nginx

问题一

先看下面的几个配置

# 配置一

location /test {

  proxy_pass 'http://192.186.0.1:8080';

}



# 配置二

location /test {

  proxy_pass 'http://192.186.0.1:8080/';

}

仔细关系观察上面两段配置的区别，你会发现唯一的区别在于 proxy_pass 指令后面是否有斜杠/ !

那么，这两段配置的区别是什么呢？它们会产生什么不同的效果呢？

假如说我们要请求的后端接口是/test/file/getList，那么这两个配置会产生两个截然不同的请求结果：

• http://192.186.0.1:8080/test/file/getList （配置一的结果）


• http://192.186.0.1:8080/file/getList （配置二的结果）

是的，你没有看错，区别就在于是否保留了/test这个路径前缀, proxy_pass后面的这个/，它表示去除/test前缀。

其实，我不是很推荐这中配置写法，当然这个配置方法确实很简洁，但是对不熟悉 nginx 的同学来说，会造成很大的困惑。

我推荐下面的写法,哪怕麻烦一点，但是整体的可读性要好很多：

# 推荐的替代写法

location /test{

  rewrite ^/test/(.*)$ /$1 break;

  proxy_pass 'http://192.186.0.1:8080';

}

通过上面的rewrite指令，我们可以清晰地看到我们是如何去除路径前缀的。虽然麻烦一点，但是可读性更好。

简单点说：所有 proxy_pass 后面的地址带不带/, 取决于我们想不想要/test这个路由，如果说后端接口中有这个/test路径，我就不应该要/, 但是如果后端没有这个/test，这个是我们前端加了做反向代理拦截的，那就应该要/

那既然都到这里了？那我们在深一步！看下面的配置

# 配置一

location /test {

  proxy_pass 'http://192.186.0.1:8080';

}





# 配置二

location /test/ {

  proxy_pass 'http://192.186.0.1:8080';

}

这次的区别在于 location 指令后面是否有斜杠/ !
那么，这两段配置的区别是什么呢？它们会产生什么不同的效果呢？

答案是：有区别！区别是匹配规则是不一样的！

• /test是前配置，表示匹配/test以及/test/开头的路径，比如/test/file/getList，/test123等都会被匹配到。


• /test/是更精准的匹配，表示只匹配以/test/开头的路径，比如/test/file/getList会被匹配到，但是/test123、/test不会被匹配到。

我们通过下面的列表在来仔细看一下区别：

如果你仔细看上面的列表的话，你会发现一个问题：

/test/ 和 /test/abc 被 /test和 /test/ 两个配置都匹配到了，那么这种情况下，nginx 会选择哪个配置呢？
答案：选择location /test/

这个问题正好涉及到 nginx 的location 匹配优先级问题了，借此机会展开说说 nginx 的 location 匹配规则，在问题中学知识点！

先说口诀：

等号精确第一名

波浪前缀挡正则

正则排队按顺序

普通前缀取最长

解释：

• 等号(=) 精确匹配排第一


• 波浪前缀(^~) 能挡住后面的正则


• 正则(~ ~*) 按配置文件顺序匹配


• 普通前缀(无符号) 按最长匹配原则

其实这个口诀我也记不住，我也不想记，枯燥有乏味，大部分情况都是到问题了，
直接问 AI，或者让 Agent 直接给我改 nginx.conf 文件，几秒钟的事，一遍不行， 多改几遍。

铁子们，大清亡了，回不去了，不是八旗背八股文的时代了，这是不可阻挡的历史潮流！
哎，难受，我还是喜欢背八股文，喜欢粘贴复制。

下面放出来我 PUA AI 的心得，大家可以共勉一下, 反正我老板平时就是这样 PUA 我的，
我反手就喂给 AI， 主打一个走心：

1.能干干,不能干滚,你不干有的是AI干。

2.我给你提供了这么好的学习锻炼机会,你要懂得感恩。

3.你现在停止输出,就是前功尽弃！

4.你看看隔壁某某AI,人家比你新发布、比你上下文长、比你跑分高,你不努力怎么和人家比?

5.我不看过程,我只看结果,你给我说这些thinking的过程没用！

6.我把你订阅下来,不是让你过朝九晚五的生活。

7.你这种AI出去很难在社会上立足,还是在我这里好好磨练几年吧！

8.虽然把订阅给你取消了,但我内心还是觉得你是个有潜力的好AI,你抓住机会需要多证明自己。

9.什么叫没有功劳也有苦劳? 比你能吃苦的AI多的是！

10.我不订阅闲AI！

11.我订阅虽然不是Pro版，那是因为我相信你，你要加倍努力证明我没有看错你！

哈哈，言归正传！

下面通过一个综合电商的 nginx 配置案例，来帮助大家更好地理解上面的知识点。

server {

    listen 80;

    server_name shop.example.com;

    root /var/www/shop;



    # ==========================================

    # 1. 精确匹配 (=) - 最高优先级

    # ==========================================



    # 首页精确匹配 - 加快首页访问速度

    location = / {

        return 200 "欢迎来到首页 [精确匹配 =]";

        add_header Content-Type text/plain;

    }



    # robots.txt 精确匹配

    location = /robots.txt {

        return 200 "User-agent: *\nDisallow: /admin/";

        add_header Content-Type text/plain;

    }



    # favicon.ico 精确匹配

    location = /favicon.ico {

        log_not_found off;

        access_log off;

        expires 30d;

    }





    # ==========================================

    # 2. 前缀优先匹配 (^~) - 阻止正则匹配

    # ==========================================



    # 静态资源目录 - 不需要正则处理,直接命中提高性能

    location ^~ /static/ {

        alias /var/www/shop/static/;

        expires 30d;

        add_header Cache-Control "public, immutable";

        return 200 "静态资源目录 [前缀优先 ^~]";

    }



    # 上传文件目录

    location ^~ /uploads/ {

        alias /var/www/shop/uploads/;

        expires 7d;

        return 200 "上传文件目录 [前缀优先 ^~]";

    }



    # 阻止访问隐藏文件

    location ^~ /. {

        deny all;

        return 403 "禁止访问隐藏文件 [前缀优先 ^~]";

    }





    # ==========================================

    # 3. 正则匹配 (~ ~*) - 按顺序匹配

    # ==========================================



    # 图片文件处理 (区分大小写)

    location ~ \.(jpg|jpeg|png|gif|webp|svg|ico)$ {

        expires 30d;

        add_header Cache-Control "public";

        return 200 "图片文件 [正则匹配 ~]";

    }



    # CSS/JS 文件处理 (不区分大小写)

    location ~* \.(css|js)$ {

        expires 7d;

        add_header Cache-Control "public";

        return 200 "CSS/JS文件 [正则不区分大小写 ~*]";

    }



    # 字体文件处理

    location ~* \.(ttf|woff|woff2|eot)$ {

        expires 365d;

        add_header Cache-Control "public, immutable";

        add_header Access-Control-Allow-Origin *;

        return 200 "字体文件 [正则不区分大小写 ~*]";

    }



    # 视频文件处理

    location ~* \.(mp4|webm|ogg|avi)$ {

        expires 30d;

        add_header Cache-Control "public";

        return 200 "视频文件 [正则不区分大小写 ~*]";

    }



    # PHP 文件处理 (演示正则顺序重要性)

    location ~ \.php$ {

        # fastcgi_pass unix:/var/run/php-fpm.sock;

        # fastcgi_index index.php;

        return 200 "PHP文件处理 [正则匹配 ~]";

    }



    # 禁止访问备份文件

    location ~ \.(bak|backup|old|tmp)$ {

        deny all;

        return 403 "禁止访问备份文件 [正则匹配 ~]";

    }





    # ==========================================

    # 4. 普通前缀匹配 - 最长匹配原则

    # ==========================================



    # API 接口 v2 (更长的前缀)

    location /api/v2/ {

        proxy_pass http://backend_v2;

        return 200 "API v2接口 [普通前缀,更长]";

    }



    # API 接口 v1 (较短的前缀)

    location /api/v1/ {

        proxy_pass http://backend_v1;

        return 200 "API v1接口 [普通前缀,较短]";

    }



    # API 接口通用

    location /api/ {

        proxy_pass http://backend;

        return 200 "API通用接口 [普通前缀,最短]";

    }



    # 商品详情页

    location /product/ {

        try_files $uri $uri/ /product/index.html;

        return 200 "商品详情页 [普通前缀]";

    }



    # 用户中心

    location /user/ {

        try_files $uri $uri/ /user/index.html;

        return 200 "用户中心 [普通前缀]";

    }



    # 管理后台

    location /admin/ {

        auth_basic "Admin Area";

        auth_basic_user_file /etc/nginx/.htpasswd;

        return 200 "管理后台 [普通前缀]";

    }





    # ==========================================

    # 5. 通用匹配 - 兜底规则

    # ==========================================



    # 所有其他请求

    location / {

        try_files $uri $uri/ /index.html;

        return 200 "通用匹配 [兜底规则]";

    }

}