哈喽，各位掘金的“打工人”们，大家好！👋

还记得咱们上一篇聊过的 Tailwind CSS 入门（在这里详细讲解了如何配置TailwindCss） 吗？当时我们不仅揭开了原子化 CSS 的神秘面纱，还稍微带了一嘴“受控组件”的概念。

今天，咱们不玩虚的，直接实战！🚀

我们要用 React 配合 Tailwind CSS，从零打造一个现代、优雅、且交互细腻的登录页面。

别担心，虽然说是“实战”，但我的风格你懂的：轻松愉快，知识硬核。我会把代码掰开了、揉碎了讲给你听，保证你不仅能学会写，还能懂得为什么要这么写。

准备好了吗？系好安全带，老司机要发车了！🚌💨

🎯 我们的目标

我们要做的不是一个死板的 HTML 页面，而是一个有灵魂的 React 组件。它包含：

最终效果？就像你每天用的那些大厂 App 一样丝滑。✨

🛠️ 准备工作：兵马未动，粮草先行

首先，确保你的环境里有 React 和 Tailwind CSS。如果你是 Vite 用户，这简直是分分钟的事。

在这个项目中，我们还需要一个特别好用的图标库：lucide-react。

npm install lucide-react

# 或者

pnpm add lucide-react

它体积小、图标全、风格统一，绝对是开发利器。

🏗️ 第一步：骨架与画布 —— 布局的艺术

一切从 App.jsx 开始。

我们先看最外层的结构。想象一下，你是个画家，得先铺好画布。

export default function App() {

  // ... 逻辑部分稍后讲 ...



  return (

    // 1. 外层容器：全屏背景，居中布局

    <div className="min-h-screen bg-slate-50 flex items-center justify-center p-4">

      {/* ... 卡片 ... */}

    </div>

  )

}

📝 代码详解

• min-h-screen: 核心！ 这让容器的高度至少为屏幕高度（100vh）。如果内容不够多，背景也能铺满全屏；内容多了，它能自动延伸。告别尴尬的“白底漏出”。


• bg-slate-50: 给背景来点极其淡雅的灰。纯白（#fff）太刺眼，Slate-50 刚刚好，高级感这就来了。


• flex items-center justify-center: Flexbox 三连。这是最经典的垂直水平居中方案。不管你的屏幕多大，登录框永远稳坐 C 位。


• p-4: 给四周留点余地，防止在小屏幕手机上内容贴边。

📦 第二步：卡片设计 —— 拟物感的回归

接下来是那个漂浮在屏幕中央的白色卡片。

<div className="relative z-10 w-full max-w-md bg-white rounded-3xl shadow-xl shadow-slate-200/60 border-slate-100 p-8 md:p-10">

  {/* ... 内容 ... */}

</div>

📝 代码详解

这里面的学问可大了：

🧠 第三步：注入灵魂 —— React 状态管理

界面写得再好看，不能动也是白搭。我们要用 React 的 Hooks 来赋予它生命。

import { useState } from 'react';



export default function App() {

  // 1. 表单数据状态：单一数据源

  const [formData, setFormData] = useState({    

    email: '',

    password: '',

    remember: false // 虽然 UI 里没画，但逻辑我们要预留好

  });



  // 2. UI 交互状态

  const [showPassword, setShowPassword] = useState(false); // 密码显隐

  const [isLoading, setIsLoading] = useState(false);       // 加载中状态



  // ...

}

💡 为什么这么设计？

我们没有为 email 和 password 分别创建 state（比如 email, setEmail），而是用一个对象 formData 统一管理。
这样做的好处是：当表单字段变多时（比如注册页有10个空），我们不需要写10个 useState，代码更整洁，扩展性更强。

⚡ 第四步：抽象事件处理 —— 优雅的 handleChange

这是很多新手容易写乱的地方。看仔细了，这一段代码非常通用，建议背诵！

  // 抽象的表单变更处理函数

  const handleChange = (e) => {

    // 解构出我们需要的信息

    // name: 哪个输入框变了？

    // value: 变成了什么值？

    // type/checked: 专门处理 checkbox

    const { name, value, type, checked } = e.target;



    // 状态更新

    setFormData((prev) => ({

      ...prev, // 保留之前的其他字段

      // 动态属性名：[name]

      // 如果是 checkbox 用 checked，否则用 value

      [name]: type === 'checkbox' ? checked : value,

    }))

  }

📝 深度解析

🎨 第五步：表单组件 —— 细节狂魔

接下来是重头戏：输入框。这里我们用到了 Tailwind 极其强大的 group 和 peer 特性。

邮箱输入框

<div className="space-y-2">

  <label className="text-sm font-medium text-slate-700">Email:</label>

  

  {/* group: 父容器标记 */}

  <div className="relative group">

    

    {/* 图标：绝对定位 */}

    <div className="absolute inset-y-0 left-0 pl-4 flex items-center pointer-events-none text-slate-400 group-focus-within:text-indigo-600 transition-colors"> 

      <Mail size={18} />

    </div>



    {/* 输入框 */}

    <input 

      type="email" 

      name="email" 

      required 

      value={formData.email}

      onChange={handleChange}

      placeholder="name@company.com"

      className="block w-full pl-11 pr-4 py-3 bg-slate-50 border border-slate-200 rounded-xl text-slate-900 placeholder:text-slate-400 focus:outline-none focus:ring-2 focus:ring-indigo-600/20 focus:border-indigo-600 transition-all"

    />

  </div>

</div>

🤯 这里的 CSS 技巧太炸裂了！

🔐 第六步：密码框与显隐切换

密码框多了一个“眼睛”按钮，逻辑稍微复杂一点点。

<div className="relative group">

  {/* 左侧锁图标 (同上，略) */}

  

  <input 

    // 动态类型：根据状态决定是明文还是密文

    type={showPassword ? "text" : "password"} 

    name="password"

    // ...

  />

  

  {/* 右侧切换按钮 */}

  <button

    type="button" // 必须写！否则默认是 submit 会触发表单提交

    onClick={() => setShowPassword(!showPassword)}

    className="absolute inset-y-0 right-0 pr-4 flex items-center text-slate-400 hover:text-slate-600 transition-colors"

  >

    {/* 根据状态切换图标 */}

    {showPassword ? <EyeOff size={18} /> : <Eye size={18} />}

  </button>

</div>

📝 关键点

🚀 总结

看到这里，你应该已经发现，使用 Tailwind CSS + React 开发界面，实际上是一种搭积木的体验。

• Tailwind 提供了极其丰富的原子积木（Utility Classes），让你不用写一行 CSS 就能堆砌出精美的样式。


• React 提供了胶水和传动装置（State & Props），让这些积木动起来，响应用户的操作。

我们学到了什么？

课后作业 📝

现在的登录点击后还没有实际效果。你可以尝试完善 handleSubmit 函数，加一个 setTimeout 模拟网络请求，把 isLoading 状态用起来，给按钮加一个“加载中”的转圈圈动画。

前端开发很有趣，Tailwind 让它变得更有趣。希望这篇文章能让你感受到原子化 CSS 的魅力！

喜欢的话，点个赞再走吧！我们下期见！👋

本文代码基于 React 18 + Tailwind CSS 3.x + Lucide React 编写。

你是不是也有这些困惑

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

• 流程引擎（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行代码解决的，就别上框架。

技术是为业务服务的，不是为了炫技。

务实点，别整那些虚的。

就这样。

先声明，本文不是贩卖焦虑，只是自己的一点拙见，没有割韭菜的卖课、副业、保险广告，请放心食用。

2022 年初，前司开始了轰轰烈烈的「降本增笑」运动，各部门严格考核机器成本和预算。当然，最重要的还是「开猿节流」。

幸好，我所在部门是盈利的，当时几乎没有人受到波及。

据说，现在连餐巾纸都从三层的「维达」换成两层的「心心相印」了，号称年节约成本 100 多万。我好奇的是，擦屁股时多少会沾点 💩 吧？这下，真是名正言顺的 💩 山代码了。

2022 年 7 月底，因为某些原因，结束 10 年北漂回老家，换了个公司继续搬砖。

2023 年，春节后不久，现司搞「偷袭」，玩起了狼人杀，很多小伙伴被刀：

清晨接到电话通知，上午集体开会，IT 收回权限，中午滚蛋

好在是头一回，补偿非常可观，远超法律规定的「N+1」。

2024 年，平安夜，无事发生。

2025 年 1 月，公司年会，趣味运动会，有个项目是「财源滚滚」，下图这样的：

有个参赛的老哥调侃道，这项目名字不吉利啊，不应该参加的。无巧不成书，年后他被刀了。。。

这次的规模远小于 2023 年，但 2025 年也不太平，「脉脉」上陆续有人说被刀或者不续签，真假未知。

实话说，我之前从未担心过被裁，毕竟：

名校硕士，经历多个大厂，有管理经验

热爱编程，工作认真负责，常年高绩效

但是，随着 AI 的快速迭代，我现在感觉自己随时可能被刀了。AI 能胜任 log 分析、新功能开发、bug 修复等绝大部分日常工作，而且都完成的很好。再配合 AI 自己写的MCP，效率肉眼可见的提高。

亲身体验，数百人开发的千万行代码级别的项目，混合了Java/Kotlin/OC/C++/Python等各种语言。跟Cursor聊了几句，它就找到原因并帮忙修复了。如果是自己看代码、问人、加 log、编译，至少得半个小时。

那还要码农干啥呢？即使是留下来背锅，也要不了这么多啊。

距离上次「狼人杀 」，三年之期已到。今年会有「狼人杀 2.0」吗？我还能平稳落地吗？

无所谓了，我早已准备好后路：

头盔和衣服真是我买的，还有手套未入镜，我感觉设计很漂亮，等天气暖和后，当骑行服穿。

汽车，小踏板，大踏板，足以覆盖滴滴、外卖、闪送三大朝阳行业。家里还有个小电驴，凑合能放到后备箱，承接代驾业务问题不大。

以上，虽然是开玩笑，但我对「是否被刀、何时被刀」，真的是无所谓。因为：

一个人的命运啊，当然要靠自我奋斗，但也要考虑历史的进程

公司为了长远的发展，刀人以降低成本，再用 AI 来提高效率，求得股价长红。对此，我十分理解，换我当老板，也会这么干。

作为牛马，想太多没用，我们左右不了这些事。不夸张的说，99.9999% 的码农是不可能干到退休的，和死亡一样，被刀只是早晚的事。更扎心的是：

人不是老了才会死，而是随时会死

当下的工作也一样，并不是摸鱼或者捅娄子才会被刀，而是随时会被刀，与个人的努力、绩效关系不大。常年健身的肌肉男，也可能猝死，只是概率低点，并不是免死金牌。

生命，从受精的那一刻起，就在走向终点。工作，从入职的那一刻起，就在走向(主动/被动)离职。

所以，虽然我现在感觉自己随时可能被 AI 替代，但我的心态一直都没变，就是标题所言：

做好自己的份内工作，等着被裁

不是消极怠工，我始终认真完成每一项任务，该加班加班。并非为了绩效，是因为自己的责任心，要对的起工资。至于公司哪天让我滚蛋，我决定不了，更改变不了。就像对待死亡一样，坦然接受之，给够补偿就好。

对于 AI，还想再啰嗦两句：

滚蛋之后呢？我不知道，现在有多少公司愿意招 40 岁高龄码农？据说前司招聘 35 岁普通员工都要 VP 审批了，真是小刀剌屁股，开了眼了。

好在，我家人的物质欲望极低，对衣服、手机、汽车没有任何追求，老婆不用化妆品和护肤品，也没买过一个包。即使不上班，积蓄也能撑一段时间。

所以，强烈建议当前北上广深拿高薪的老哥老妹们，除非万不得已，千万不要像我一样断崖式降薪回老家。趁年轻，搞钱比啥都重要。

对了，我目前有两个利用自身优势的基于 AI 的创业方向。网友们帮忙把把关，如果哪天真失业了，看能否拉到几个亿的风投，谢谢！

面试导航 是一个专注于前、后端技术学习和面试准备的 免费 学习平台，提供系统化的技术栈学习，深入讲解每个知识点的核心原理，帮助开发者构建全面的技术体系。平台还收录了大量真实的校招与社招面经，帮助你快速掌握面试技巧，提升求职竞争力。如果你想加入我们的交流群，欢迎通过微信联系：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 这一次的升级，不仅提升了开采效率，还让更多人用上了这把利器。

期待大家亲自体验，也欢迎在评论区分享你的使用场景与发现。

2025 年终总结：25 岁，从“混吃等死”到别人眼中的“技术专家”

两年前的春节假期，某天。在一所面积不大的小房里，住着三个人。

那时的我，还是个凭运气混进大公司、天天写 CRUD 混吃等死的前端“小卡拉米”。趁着春节假期，我戴着耳机，沉浸在游戏世界里。突然，客厅传来一声闷响。

我疑惑地摘下耳机：“什么声音？”

回头望去，我看到奶奶仰面躺在沙发上——她晕倒了。

那是我第一次见到我最亲爱的亲人病倒在面前。慌乱中，我给在外打牌的父亲拨去了电话。最后所幸并无大碍，但在那一刻，我知道：我不能再这样混下去了，我需要努力。

两年后的今天，再回头看：

• 我成为了团队中不可或缺的技术核心


• 我成为了稀土掘金 2025 年度优秀创作者


• 我开源的项目累计获得 1K+ GitHub Star


• 我开始频繁出现在 Three.js 官方推特的转发列表中


• 也第一次，被别人称为「技术专家」

前言：前端版“萧炎”？不，是鸽子王

我无意想去将过去两年到底是如何度过的写成文章，把这篇年终总结写成“前端版萧炎”的自传。老实说我也想不起来是怎么过的。上面那段沉重的开场白，就当是我为自己小小的骄傲一下吧。

好了！STOP！沉重的话题到此为止。让我们一起来看看，“鸽子王”老何今年到底干了些什么事吧！

1.所在之平台：数据与感谢

首先，让我们来看看今年在平台上的具体“战绩”。今年一共写了多少篇文章呢？

哇！居然有足足 9 篇之多！ 这个数量真是闻者伤心、听者落泪，运营看了想打人（右边狐尼克真的是运营催更我时的表情 be like...）。不过好在数据还算过得去，收获了 1217 名粉丝。真的特别特别感谢你们！不多说了，就我这“随缘更新”的频率还能有粉丝，真的得给“义父们”磕一个。

在此期间，我也收获了非常不错的流量，感谢各大网友、群友和平台运营老师的大力扶持。

最终，我获得了 「稀土掘金 2025 年度优秀创作者」 的荣誉。当时运营老师通知我的时候，我的第一反应是：

泰裤辣！兄弟们也是好起来了！

说真的，能拿这个奖完完全全归功于万能的群友们和运营老师满满的 Push，是你们的监督让我得以将写文章的习惯（勉强）坚持下去！

2.所做之项目：从“夯”到“拉”的锐评

来到项目环节，让我以极其客观（自我检讨）的视角，锐评一下今年开源的项目吧！

🏝️ Island —— 2.5D 卡通风个人简历\

自我评价：人上人

island 对现在的我来说，确实存在不少问题：

• 画面风格：三渲二的效果还需优化，仔细看距离小时候在 PSP 上玩的游戏风格还有差距，后续计划加入自定义后处理通道来调节。


• UI 设计：当时用 DALL·E 3 生成的 UI 比较简陋，后续会用 Nano-banana-pro 全面改进 UI 风格。


• 兼容性：移动端适配？不存在的，手机和平板用户只能干瞪眼 = =。


• 交互性：可互动内容单调，靠近物体没有视觉反馈。


• 展示方式：玩家需要到场景上方点击告示牌展示新项目，方式太单一，和网页没啥区别！

但话又说回来，这确实是我第一个有点“出圈”的项目。也许每个人回看以前的代码都会觉得稚嫩，左看右看能挑出一堆毛病，但不可否认它在我心中的地位。综合下来，给个**“人上人”**的评价！后面的改动还能在掘金多水两篇文章，美滋滋。

🏙️ CubeCity —— 卡通城市放置系统

自我评价：项目顶尖，作者“拉完了”

CubeCity 是我 GitHub 上 Star 最多的项目，单个项目贡献了 877 Star。玩法参考了《卡牌城镇》，支持随意建造、拆除、升级、搬迁建筑。UI 贴合 Low Poly 风格，在国外社区也很讨喜。

但 Star 多不代表没问题：

• 性能：渲染帧率堪忧，比如 GTX 1660 Ti 这种显卡都跑不满 60 FPS。


• 生气：道路上没有汽车和小人跑动，城市显得空荡荡。


• 兼容性：移动设备又双叒没做兼容？！GitHub 上提的 Issue 也不回？可恶的鸽子王！


• 功能缺失：说好的成就系统呢？经济系统呢？社交排行榜呢？

何贤你在干嘛？总而言之，这个项目简直是鸽到没朋友，最鸽的一集！X 上评论不回，GitHub 上 Issue 装死。要不是项目底子还行，我真的要骂人了！

综合下来项目给到顶尖，但是开发者给到 拉完了 啊！

Third-Person-MC——第三人称我的世界

自我评价：夯

这个项目掘友们可能没怎么听过，但在群里应该多多少少见识过。这是目前对我来说最复杂的一个项目！

该项目具备多种生态地貌、无限地形生成与自适应相机等核心特性，不久的将来，即将正式登陆掘金平台与大家见面。至于是否会进一步扩展联机系统，目前尚无定论。相关内容，我会在后续发布的专题文章中为大家详细解读。

总体来说还不错！实机测试在 GTX 1660 Ti 的笔记本上也能稳定 30 帧！算是一个非常有意思的探索。综合评价：夯。

好了好了打住！今年说实话还是开源了不少项目！但是不能在这占用篇幅！在此我直接就是一个项目大合影

以及对于我来说所有项目从夯到拉的排名如下：

3.所遇之好友：良师益友

近年最幸运的事，就是遇到了一个很好的领导，以及一群志同道合、相互勉励的朋友。

关于“冷爷”

在工作上，我遇到了一位好领导，但我更愿称他为好朋友——冷爷。 平时群友或合作伙伴可能觉得我是个温和的人，可一旦切入工作模式，我就会变成大家口中的“压力怪”。因此曾有一段时间，我和办公环境有些格格不入。冷爷作为 Leader，真的起到了至关重要的润滑作用。 生活中，冷爷也经常带我出去玩。那段时间我真是“两耳不闻窗外事，一心只想学技术”，彻彻底底的宅男一枚。要不是冷爷拉着我游山玩水，我可能真就成了那种“代码敲得飞起、话却说不清楚”的刻板极客。 他是一个好领导，更是一个好朋友。在这里想对冷爷说一声：谢谢！

关于 Web3D 圈子

随着深入学习 Web3D，我微信里多了很多耕耘于此的朋友。虽然大家细分领域不同——有做可视化大屏的，有做 3D 看车/看房的，有研究 NVIDIA Isaac Sim 的，也有做数字工厂/机械臂的。甚至有些曾是我在视频网站上仰望的偶像，现在也成了列表好友。

大家聚在一起分享技术，扯皮打趣，大佬们时不时冒泡答疑。这个圈子很小，抬头不见低头见，但真的很少出现拉踩或诋毁。我是在群友们的“夸夸”中一步步走到这里的。 这种正反馈非常奇妙：动力来自群友的鼓励和大佬的认可，而这些又促使我创造出更好的项目！

4. 所想：运气表面积

最近我了解到一个非常有趣的观点，叫 Luck Surface Area（运气表面积），最早来自 Jason Roberts：

你生活中会有多少‘无心插柳柳成荫’的意外之喜？这取决于你的‘运气表面积’。 LSA（运气） = P（热爱/做事的深度） × C（传播/连接的广度）

这个乘法关系很神奇，意味着如果其中一项为零，总结果就为零：

• 只有热爱 (P)，没有传播 (C) = 孤独的耕耘者 如果你对某事极度热爱，技艺精湛，但把自己关在地下室里，从不向外界展示，那么你的“运气表面积”几乎为零。外界的机会无法穿透墙壁找到你，“酒香也怕巷子深”。


• 只有传播 (C)，没有热爱 (P) = 空洞的喧哗者 如果你擅长营销，但传播的内容缺乏内核，不是你真正热爱或擅长的东西，你可能短期获得关注，但无法建立深度的信任，真正的“好运”依然很难降临。

我觉得我是非常幸运的。优秀的 Web3D 作品天然具有视觉冲击力和社交属性，而稀土掘金平台很好地承担了“传播”的职责！

所以，并不是我选择了这个平台，而是我遇到的人、事以及平台给予的正反馈激励着我！非常感谢能看到这里的你！

5. 所规划之未来

2026 年会是什么样？我不知道。它会是我的“三年之约”，我希望自己能变成更好的人。

但我确定我一定会：

• 🛠️ 填坑：优化那些我没有完善好的项目（别骂了别骂了）。


• ✨ 创造：产出更多有趣的项目和技术文章。


• 🤝 连接：认识更多志同道合的朋友。


• 🌐 布道：将 Web3D 的魅力分享给更多的人。

6.三年之约，你会如约而至吗？

最后，如果你愿意，也在这篇文章的评论区留下属于你的「三年之约」吧！

无论是技术的精进、生活的改变，还是一个简单的愿望。让我们约定在未来的某一天回头看，一起见证彼此的蜕变！🚀

需求

先来看这样一个场景，拿一个网站举例

这里有一个常见的网站 banner 图容器，大小为为1910*560，看起来背景图完美的充满了宽度，但是图片原始大小时，却是：

它的宽度只有 1440，且 background-size 设置的是 contain ，即等比例缩放，那么可以断定它两边的蓝色是依靠背景色填充的。

那么问题来了，这是一个 轮播banner，如果希望添加一张不是蓝色的图片呢？难道要给每张图片提前标注好背景颜色吗？这显然是非常死板的做法。

所以需要从图片中提取到图片的主题色，当然这对于 js 来说，也不是什么难事，市面上已经有众多的开源库供我们使用。

探索

首先在网络上找到了以下几个库：

• color-thief 这是一款基于 JavaScript 和 Canvas 的工具，能够从图像中提取主要颜色或代表性的调色板


• vibrant.js 该插件是 Android 支持库中 Palette 类的 JavaScript 版本，可以从图像中提取突出的颜色


• rgbaster.js 这是一段小型脚本，可以获取图片的主色、次色等信息，方便实现一些精彩的 Web 交互效果

我取最轻量化的 rgbaster.js（此库非常搞笑，用TS编写，npm 包却没有指定 types） 来测试后发现，它给我在一个渐变色图片中，返回了七万多个色值，当然，它准确的提取出了面积最大的色值，但是这个色值不是图片边缘的颜色，导致设置为背景色后，并不能完美的融合。

另外的插件各位可以参考这几篇文章：

• 文章1：blog.csdn.net/weixin_4299…


• 文章2：juejin.cn/post/684490…


• 文章3：http://www.zhangxinxu.com/wordpress/2…

可以发现，这些插件主要功能就是取色，并没有考虑实际的应用场景，对于一个图片颜色分析工具来说，他们做的很到位，但是在大多数场景中，他们往往是不适用的。

在文章 2 中，作者对比了三款插件对于图片容器背景色的应用，看起来还是 rgbaster 效果好一点，但是我们刚刚也拿他试了，它并不能适用于颜色复杂度高的、渐变色的图片。

思考

既然又又又没有人做这件事，正所谓我不入地狱谁入地狱，我手写一个

整理一下需求，我发现我希望得到的是：

这样一来，就已经可以覆盖大部分需求了，1+2 可以生成相关的 主题 TAG、主题背景，3 可以使留白的图片容器完美融合。

开搞

⚠⚠ 本小节内容非常硬核，如果不想深究原理可以直接跳过，文章末尾有用法和效果图 ⚠⚠

思路

首先需要避免上面提到的插件的缺点，即对渐变图片要做好处理，不能取出成千上万的颜色，体验太差且实用性不强，对于渐变色还有一点，即在渐变路径上，每一点的颜色都是不一样的，所以需要将他们以一个阈值分类，挑选出一众相近色，并计算出一个平均色，这样就不会导致主题色太精准进而没有代表性。

对于背景色，需要按情况分析，如果只是希望做一个协调的页面，那么大可以直接使用主题色做渐变过渡或蒙层，也就是类似于这种效果

但是如果希望背景与图片完美衔接，让人看不出图片边界的感觉，就需要单独对边缘颜色取色了。

最后一个问题，如果图片分辨率过大，在遍历像素点时会非常消耗性能，所以需要降低采样率，虽然会导致一些精度上的丢失，但是调整为一个合适的值后应该基本可用。

剩余的细节问题，我会在下面的代码中解释

使用 JaveScript 编码

接下来我将详细描述 autohue.js 的实现过程，由于本人对色彩科学不甚了解，如有解释不到位或错误，还请指出。

首先编写一个入口主函数，我目前考虑到的参数应该有：

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions)

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

interface autoColorPickerOptions {

  /**

   * - 降采样后的最大尺寸（默认 100px）

   * - 降采样后的图片尺寸不会超过该值，可根据需求调整

   * - 降采样后的图片尺寸越小，处理速度越快，但可能会影响颜色提取的准确性

   **/

  maxSize?: number

  /**

   * - Lab 距离阈值（默认 10）

   * - 低于此值的颜色归为同一簇，建议 8~12

   * - 值越大，颜色越容易被合并，提取的颜色越少

   * - 值越小，颜色越容易被区分，提取的颜色越多

   **/

  threshold?: number | thresholdObj

}

概念解释 Lab ，全称：CIE L*a*b ，CIE L*a*b* 是CIE XYZ色彩模式的改进型。它的“L”（明亮度），“a”（绿色到红色）和“b”（蓝色到黄色）代表许多的值。与XYZ比较，CIE L*a*b*的色彩更适合于人眼感觉的色彩，正所谓感知均匀

然后需要实现一个正常的 loadImg 方法，使用 canvas 异步加载图片

function loadImage(imageSource: HTMLImageElement | string): Promise<HTMLImageElement> {

  return new Promise((resolve, reject) => {

    let img: HTMLImageElement

    if (typeof imageSource === 'string') {

      img = new Image()

      img.crossOrigin = 'Anonymous'

      img.src = imageSource

    } else {

      img = imageSource

    }

    if (img.complete) {

      resolve(img)

    } else {

      img.onload = () => resolve(img)

      img.onerror = (err) => reject(err)

    }

  })

}

这样我们就获取到了图片对象。

然后为了图片过大，我们需要进行降采样处理

// 利用 Canvas 对图片进行降采样，返回 ImageData 对象

function getImageDataFromImage(img: HTMLImageElement, maxSize: number = 100): ImageData {

  const canvas = document.createElement('canvas')

  let width = img.naturalWidth

  let height = img.naturalHeight

  if (width > maxSize || height > maxSize) {

    const scale = Math.min(maxSize / width, maxSize / height)

    width = Math.floor(width * scale)

    height = Math.floor(height * scale)

  }

  canvas.width = width

  canvas.height = height

  const ctx = canvas.getContext('2d')

  if (!ctx) {

    throw new Error('无法获取 Canvas 上下文')

  }

  ctx.drawImage(img, 0, 0, width, height)

  return ctx.getImageData(0, 0, width, height)

}

概念解释，降采样：降采样（Downsampling）是指在图像处理中，通过减少数据的采样率或分辨率来降低数据量的过程。具体来说，就是在保持原始信息大致特征的情况下，减少数据的复杂度和存储需求。这里简单理解为将图片强制压缩为 100*100 以内，也是 canvas 压缩图片的常见做法。

得到图像信息后，就可以对图片进行像素遍历处理了，正如思考中提到的，我们需要对相近色提取并取平均色，并最终获取到主题色、次主题色。

那么问题来了，什么才算相近色，对于这个问题，在 常规的 rgb 中直接计算是不行的，因为它涉及到一个感知均匀的问题

概念解释，感知均匀：XYZ系统和在它的色度图上表示的两种颜色之间的距离与颜色观察者感知的变化不一致，这个问题叫做感知均匀性(perceptual uniformity)问题，也就是颜色之间数字上的差别与视觉感知不一致。由于我们需要在颜色簇中计算出平均色，那么对于人眼来说哪些颜色是相近的？此时，我们需要把 sRGB 转化为 Lab 色彩空间（感知均匀的），再计算其欧氏距离，在某一阈值内的颜色，即可认为是相近色。

所以我们首先需要将 rgb 转化为 Lab 色彩空间

// 将 sRGB 转换为 Lab 色彩空间

function rgbToLab(r: number, g: number, b: number): [number, number, number] {

  let R = r / 255,

    G = g / 255,

    B = b / 255

  R = R > 0.04045 ? Math.pow((R + 0.055) / 1.055, 2.4) : R / 12.92

  G = G > 0.04045 ? Math.pow((G + 0.055) / 1.055, 2.4) : G / 12.92

  B = B > 0.04045 ? Math.pow((B + 0.055) / 1.055, 2.4) : B / 12.92



  let X = R * 0.4124 + G * 0.3576 + B * 0.1805

  let Y = R * 0.2126 + G * 0.7152 + B * 0.0722

  let Z = R * 0.0193 + G * 0.1192 + B * 0.9505



  X = X / 0.95047

  Y = Y / 1.0

  Z = Z / 1.08883



  const f = (t: number) => (t > 0.008856 ? Math.pow(t, 1 / 3) : 7.787 * t + 16 / 116)

  const fx = f(X)

  const fy = f(Y)

  const fz = f(Z)

  const L = 116 * fy - 16

  const a = 500 * (fx - fy)

  const bVal = 200 * (fy - fz)

  return [L, a, bVal]

}

这个函数使用了看起来很复杂的算法，不必深究，这是它的大概解释：

接下来实现聚类算法

/**

 * 对满足条件的像素进行聚类

 * @param imageData 图片像素数据

 * @param condition 判断像素是否属于指定区域的条件函数（参数 x, y）

 * @param threshold Lab 距离阈值，低于此值的颜色归为同一簇，建议 8~12

 */

function clusterPixelsByCondition(imageData: ImageData, condition: (x: number, y: number) => boolean, threshold: number = 10): Cluster[] {

  const clusters: Cluster[] = []

  const data = imageData.data

  const width = imageData.width

  const height = imageData.height

  for (let y = 0; y < height; y++) {

    for (let x = 0; x < width; x++) {

      if (!condition(x, y)) continue

      const index = (y * width + x) * 4

      if (data[index + 3] === 0) continue // 忽略透明像素

      const r = data[index]

      const g = data[index + 1]

      const b = data[index + 2]

      const lab = rgbToLab(r, g, b)

      let added = false

      for (const cluster of clusters) {

        const d = labDistance(lab, cluster.averageLab)

        if (d < threshold) {

          cluster.count++

          cluster.sumRgb[0] += r

          cluster.sumRgb[1] += g

          cluster.sumRgb[2] += b

          cluster.sumLab[0] += lab[0]

          cluster.sumLab[1] += lab[1]

          cluster.sumLab[2] += lab[2]

          cluster.averageRgb = [cluster.sumRgb[0] / cluster.count, cluster.sumRgb[1] / cluster.count, cluster.sumRgb[2] / cluster.count]

          cluster.averageLab = [cluster.sumLab[0] / cluster.count, cluster.sumLab[1] / cluster.count, cluster.sumLab[2] / cluster.count]

          added = true

          break

        }

      }

      if (!added) {

        clusters.push({

          count: 1,

          sumRgb: [r, g, b],

          sumLab: [lab[0], lab[1], lab[2]],

          averageRgb: [r, g, b],

          averageLab: [lab[0], lab[1], lab[2]]

        })

      }

    }

  }

  return clusters

}

函数内部有一个 labDistance 的调用，labDistance 是计算 Lab 颜色空间中的欧氏距离的

// 计算 Lab 空间的欧氏距离

function labDistance(lab1: [number, number, number], lab2: [number, number, number]): number {

  const dL = lab1[0] - lab2[0]

  const da = lab1[1] - lab2[1]

  const db = lab1[2] - lab2[2]

  return Math.sqrt(dL * dL + da * da + db * db)

}

概念解释，欧氏距离：Euclidean Distance，是一种在多维空间中测量两个点之间“直线”距离的方法。这种距离的计算基于欧几里得几何中两点之间的距离公式，通过计算两点在各个维度上的差的平方和，然后取平方根得到。欧氏距离是指n维空间中两个点之间的真实距离，或者向量的自然长度（即该点到原点的距离）。

总的来说，这个函数采用了类似 K-means 的聚类方式，将小于用户传入阈值的颜色归为一簇，并取平均色(使用 Lab 值)。

概念解释，聚类算法：Clustering Algorithm 是一种无监督学习方法，其目的是将数据集中的元素分成不同的组（簇），使得同一组内的元素相似度较高，而不同组之间的元素相似度较低。这里是将相近色归为一簇。

概念解释，颜色簇：簇是聚类算法中一个常见的概念，可以大致理解为 "一类"

得到了颜色簇集合后，就可以按照count大小来判断哪个是主题色了

  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)

现在我们已经获取到了主题色、次主题色 🎉🎉🎉

接下来，我们继续计算边缘颜色

按照同样的方法，只是把阈值设小一点，我这里直接设置为 1 （threshold.top 等都是1）

  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor

这样我们就获取到了上下左右四条边的颜色 🎉🎉🎉

这样大致的工作就完成了，最后我们将需要的属性导出给用户，我们的主函数最终长这样：

/**

 * 主函数：根据图片自动提取颜色

 * @param imageSource 图片 URL 或 HTMLImageElement

 * @returns 返回包含主要颜色、次要颜色和背景色对象（上、右、下、左）的结果

 */

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions): Promise<AutoHueResult> {

  const { maxSize, threshold } = __handleAutoHueOptions(options)

  const img = await loadImage(imageSource)

  // 降采样（最大尺寸 100px，可根据需求调整）

  const imageData = getImageDataFromImage(img, maxSize)



  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)



  // 定义边缘宽度（单位像素）

  const margin = 10

  const width = imageData.width

  const height = imageData.height



  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor



  return {

    primaryColor,

    secondaryColor,

    backgroundColor: {

      top: topColor,

      right: rightColor,

      bottom: bottomColor,

      left: leftColor

    }

  }

}

还记得本小节一开始提到的参数吗，你可以自定义 maxSize（压缩大小，用于降采样）、threshold（阈值，用于设置簇大小）

为了用户友好，我还编写了 threshold 参数的可选类型：number | thresholdObj

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

可以单独设置主阈值、上下左右四边阈值，以适应更个性化的情况。

autohue.js 诞生了

名字的由来：秉承一贯命名习惯，auto 家族成员又多一个，与颜色有关的单词有好多个，我取了最短最好记的一个 hue(色相)，也比较契合插件用途。

此插件已在 github 开源：GitHub autohue.js

npm 主页：NPM autohue.js

在线体验：autohue.js 官方首页

安装与使用

pnpm i autohue.js

import autohue from 'autohue.js'



autohue(url, {

  threshold: {

    primary: 10,

    left: 1,

    bottom: 12

  },

  maxSize: 50

})

  .then((result) => {

    // 使用 console.log 打印出色块元素s

    console.log(`%c${result.primaryColor}`, 'color: #fff; background: ' + result.primaryColor, 'main')

    console.log(`%c${result.secondaryColor}`, 'color: #fff; background: ' + result.secondaryColor, 'sub')

    console.log(`%c${result.backgroundColor.left}`, 'color: #fff; background: ' + result.backgroundColor.left, 'bg-left')

    console.log(`%c${result.backgroundColor.right}`, 'color: #fff; background: ' + result.backgroundColor.right, 'bg-right')

    console.log(`%clinear-gradient to right`, 'color: #fff; background: linear-gradient(to right, ' + result.backgroundColor.left + ', ' + result.backgroundColor.right + ')', 'bg')

    bg.value = `linear-gradient(to right, ${result.backgroundColor.left}, ${result.backgroundColor.right})`

  })

  .catch((err) => console.error(err))

最终效果

复杂边缘效果

纵向渐变效果（这里使用的是 left 和 right 边的值，可能使用 top 和 bottom 效果更佳）

纯色效果（因为单独对边缘采样，所以无论图片内容多复杂，纯色基本看不出边界）

突变边缘效果（此时用css做渐变蒙层应该效果会更好）

横向渐变效果（使用的是 left 和 right 的色值），基本看不出边界

参考资料

• zhuanlan.zhihu.com/p/370371059


• baike.baidu.com/item/%E5%9B…


• baike.baidu.com/item/%E6%A0…


• zh.wikipedia.org/wiki/%E6%AC…


• blog.csdn.net/weixin_4256…


• zh.wikipedia.org/wiki/K-%E5%…


• blog.csdn.net/weixin_4299…


• juejin.cn/post/684490…

番外

Auto 家族的其他成员

• Auto-Plugin/autofit.js autofit.js 迄今为止最易用的自适应工具


• Auto-Plugin/autolog.js autolog.js 轻量化小弹窗


• Auto-Plugin/autouno autouno 直觉的UnoCSS预设方案


• Auto-Plugin/autohue.js 本品 一个自动提取图片主题色让图片和背景融为一体的工具

原文链接：The 70% problem: Hard truths about AI-assisted coding

作者：Addy Osmani

作者信息：Google Chrome 团队成员，目前专注于浏览器性能领域，著作有：Learning JavaScript Design Patterns、Leading Effective Engineering Teams、Stoic Mind、Image Optimization 等

翻译链接：70% 困境：AI 辅助开发的残酷真相

过去几年，我一直深度参与 AI 辅助开发工作，期间发现了一个引人深思的现象：虽然工程师们普遍反映使用 AI 后生产力得到显著提升，但我们日常使用的软件质量似乎并没有明显改善。这是为什么呢？

我想我找到了答案。这个发现揭示了一些关于软件开发的基本事实，值得我们认真思考。接下来请让我分享一下我的心得。

开发者如何实际使用 AI

我观察到开发团队使用 AI 时有两种明显的模式。我们可以称之为"快速构建者"和"迭代优化者"。这两种方式都在帮助工程师（甚至非技术用户）缩短从想法到实现（或最小可行产品，MVP）的距离。

快速构建者：从零到 MVP

像 Bolt、v0 和 screenshot-to-code AI 等 AI 工具正在彻底改变项目启动的方式。这些团队通常会：

• 从设计或粗略概念开始


• 使用 AI 生成完整的初始代码库


• 在几小时或几天内（而不是几周）完成可用原型


• 专注于快速验证和迭代

这些成果往往令人印象深刻。我最近看到一位独立开发者使用 Bolt，几乎瞬间就将 Figma 设计转换成了一个可运行的 Web 应用。虽然还不能当作产品正式发布，但足以获取初步的用户反馈。

迭代优化者：日常开发

第二类开发者在日常开发工作流程中使用 Cursor、Cline、Copilot 和 WindSurf 等工具。这种方式虽然不那么引人注目，但可能引起更大的变革。这些开发者会：

• 使用 AI 进行代码补全和建议


• 利用 AI 处理复杂的重构任务


• 生成测试和文档


• 将 AI 作为问题解决的"结对编程"伙伴

但这里有个关键问题：尽管这两种方法都能显著加快开发速度，它们都存在一些不太明显的隐藏成本。

"AI 速度"的隐藏成本

当你看到一位高级工程师使用 Cursor 或 Copilot 等 AI 工具时，感觉就像在看魔术。他们可以在几分钟内搭建完整的功能，包括测试和文档。但仔细观察，你会发现一个关键点：他们并不是完全接受 AI 的建议。他们会不断地：

• 将生成的代码重构成更小、更集中的模块


• 添加 AI 忽略的边界情况处理


• 加强类型定义和接口


• 质疑架构决策


• 添加全面的错误处理

换句话说，他们在运用多年积累的工程智慧来塑造和约束 AI 的输出。AI 加速了他们的实现过程，但他们的专业知识才是保持代码可维护性的关键。

初级工程师往往会忽略这些关键步骤。他们更容易接受 AI 的输出，导致我称之为"纸牌屋代码"的现象——看起来完整，但在现实的压力下会崩溃。

知识悖论

我发现的最反直觉的事情是：AI 工具对有经验的开发者帮助更大，而不是初学者。这似乎是反常的——AI 不是应该让编程更加大众化吗？

现实是，AI 就像是你团队中一个非常热心的初级开发者。他们可以快速写代码，但需要不断的监督和修正。你知道得越多，就越能正确引导他们。

这就产生了我称之为"知识悖论"的现象：

• 高级开发者使用 AI 加速他们已经知道如何做的事情


• 初级开发者试图使用 AI 学习该做什么


• 结果差异显著

我看到高级工程师使用 AI 来：

• 快速实现他们已经理解的想法


• 生成基本功能，然后进行改进


• 探索已知问题的替代方法


• 自动化常规编码任务

而初级工程师往往：

• 接受不正确或过时的解决方案


• 忽略关键的安全和性能考虑


• 难以调试 AI 生成的代码


• 构建他们不完全理解的脆弱系统

70% 问题：AI 的学习曲线悖论

最近一条 推文 完美地概括了我在长期观察到的现象：非工程师使用 AI 编码时会遇到一个令人沮丧的瓶颈。他们可以非常快速地完成 70% 的工作，但最后的 30% 却变成了收益递减的劳动。

"70% 问题"揭示了当前 AI 辅助开发的一个关键点。最初的进展像魔法一样——你可以描述你想要的东西，AI 工具如 v0 或 Bolt 会生成一个看起来很令人印象深刻的工作原型。但随后你必须面对卡壳的现实。

两步回退模式

接下来通常会发生的事情一般是：

• 你试图修复一个小错误


• AI 提出一个看起来合理的更改


• 这个修复导致其他问题


• 你让 AI 修复新问题


• 这又引发了更多问题


• 如此反复

对于非工程师来说，这个循环尤其痛苦，因为他们缺乏理解实际问题的心智模型。当有经验的开发者遇到错误时，他们可以基于多年的模式识别来推理潜在原因和解决方案。没有这种背景，你基本上是在玩打地鼠游戏，处理你不完全理解的代码。

学习悖论的延续

这里有一个更深层次的问题：AI 编码工具对非工程师友好的特性（为你处理复杂性）实际上可能会阻碍学习。当代码"凭空出现"而你不理解背后原理时：

• 你不会精进你的 debug 技能


• 你错过了学习基本编程模式的机会


• 你无法独立做技术架构决策


• 你难以维护和改进代码

这就产生了一种依赖性，你需要不断回到 AI 去修复问题，而不是精进自己处理问题的专业知识。

知识差距

我见过最成功的非工程师使用 AI 编码工具时采取了一种混合方法：

但这需要耐心，需要倾注时间，这就与许多人希望通过使用 AI 工具实现的目标正好相反。

对未来的影响

"70% 问题"表明，当前的 AI 编码工具最好被视为：

• 有经验开发者的原型加速器


• 致力于理解开发的人的学习辅助工具


• 快速验证想法的 MVP 生成器

但它们还不是许多人所希望的编程大众化解决方案。最后的 30%，也就是使软件达到生产就绪、可维护和稳健的部分，仍然需要真正的工程知识。

那好消息是？随着工具的改进，这个差距可能会缩小。但目前，最务实的方法是使用 AI 加速学习，而不是完全取代它。

实际有效的做法：实用模式

在观察了几十个团队之后，我发现以下做法是有效的：

1. "AI 初稿"模式

• 让 AI 生成基本实现


• 手动审查并重构以实现模块化


• 添加全面的错误处理


• 编写详尽的测试


• 记录关键决策

2. "持续对话"模式

• 为每个不同任务启动新的 AI 对话


• 保持上下文集中和最小化


• 频繁审查和提交更改


• 保持紧密的反馈循环

3. "信任但验证"模式

• 使用 AI 进行初始代码生成


• 手动审查所有关键路径


• 自动化测试边界情况


• 定期进行安全审计

展望未来：AI 的真正承诺？

尽管存在这些挑战，我对 AI 在软件开发中的角色仍然持乐观态度。关键是要理解它真正擅长的是什么：

这对你意味着什么？

如果你刚开始使用 AI 辅助开发，以下是我的建议：

代理性软件工程的崛起

随着我们进入 2025 年，AI 辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们原型和迭代的方式，但我相信我们正处于一个更重大变革的边缘：代理性（agentic）软件工程的崛起。

我所说的"代理性"是什么意思？这些系统不再只是响应提示，而是能够计划、执行和迭代解决方案，具有越来越高的自主性。

如果你对代理感兴趣，包括我对 Cursor/Cline/v0/Bolt 的看法，你可能会对我最近在 JSNation 的演讲 感兴趣。

我们已经看到了这种趋势的早期迹象：

从响应者到合作者

当前的工具大多在等待我们的命令。但看看像 Anthropic Claude 的计算机使用功能，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是自动补全，它们实际上在理解任务并主动解决问题。

想象一下调试：这些代理不仅仅是提出修复建议，它们可以：

• 主动识别潜在问题


• 启动并运行测试套件


• 检查 UI 元素并捕获截图


• 提出并实施修复


• 验证解决方案是否有效（这可能是一个大问题）

多模态的未来

下一代工具可能不仅仅是处理代码——它们可以无缝集成：

• 视觉理解（UI 截图、原型、图表）


• 语言对话


• 环境交互（浏览器、终端、API）

这种多模态能力意味着它们可以像人类总揽全局地理解和处理软件，而不仅仅是在代码层面。

自主但受指导

我从与这些工具合作中获得的关键见解是，未来不是 AI 取代开发者，而是 AI 成为一个越来越有能力的合作者，能够在尊重人类指导和专业知识的同时采取主动行动。

2025 年最有效的团队可能是那些学会：

• 为他们的 AI 代理设定明确的边界和指南


• 建立强大的架构模式，使代理可以介入其中，一起工作


• 创建有效的人类和 AI 能力之间的反馈循环


• 在利用 AI 自主性的同时保持人类监督

英语优先的开发环境

正如 Andrej Karpathy 所指出的：

"英语正在成为最热门的新编程语言。"

这是我们与开发工具互动方式的根本转变。清晰思考和准确沟通的能力变得和传统编码技能一样重要。

这种向代理性开发的转变将要求我们升级我们的技能：

• 更强的系统设计和架构思维


• 更好的需求规范和沟通


• 更多关注质量保证和验证


• 增强的人类和 AI 能力之间的协作

软件作为技艺的回归？

虽然 AI 使得构建软件比以往任何时候都更容易，但我们有失去一些关键东西的风险——创造真正经过打磨的、高质量的艺术。

演示质量陷阱

这已经成为一种模式：团队使用 AI 快速构建令人印象深刻的演示。主干流程非常丝滑，投资者和社交网络都被惊艳到了。但当真正的用户开始点击时？那时问题就出现了。

我自己就遇到了这些情况：

• 对普通用户毫无意义的错误信息


• 导致应用崩溃的边界情况


• 从未清理的混乱 UI 状态


• 完全忽略的可访问性（Accessibility）


• 在较慢设备上的性能问题

正是这些看似低优先度的 bug 决定了用户是否喜欢这个软件。

失落的匠心

创建真正“自助”软件（用户永远不需要联系支持的那种）需要不同的思维模式：

• 认真处理所有错误信息


• 测试低速网络表现


• 优雅地处理每一个边界情况


• 使功能易于发现


• 与真正的（通常是不懂技术的）用户一起测试

这种关注细节的态度（也许）不能由 AI 生成。它来自同理心、经验和对技艺的深切关怀。

个人软件开发的复兴

我相信我们将看到个人软件开发的复兴。随着市场充斥着 AI 生成的 MVP，那些脱颖而出的产品将会是由这样的开发者构建的：

• 为他们的技艺感到自豪


• 关心细节


• 专注于完整的用户体验


• 为边界情况构建


• 创建真正的自助服务体验

但讽刺的是 AI 工具可能会促成这种复兴。通过由 AI 处理常规编码任务，让开发者能够专注于最重要的事情——创建真正服务和取悦用户的软件。

结论

AI 并没有使我们的软件质量显著提高，因为软件质量（也许）从来不是主要受编码速度限制的。软件开发的难点——理解需求、设计可维护的系统、处理边界情况、确保安全性和性能——仍然需要人类的判断。

AI 所做的是让我们更快地迭代和实验，可能通过更快速的探索导致更好的解决方案。但前提是我们保持我们的工程纪律，并将 AI 作为工具，而不是取代良好软件实践的替代品。记住：目标不是更快地编写更多代码，而是构建更好的软件。明智地使用 AI 可以帮助我们做到这一点。但最终，定义并做到"更好"的仍应是我们人类。

你在 AI 辅助开发方面的经验如何？我很想在评论中听到你的故事和见解。

续集

超越 70%：最大化 AI 开发中不可或缺的 30%

很多程序员沉迷于“氛围编程”，而忘了自己存在的价值：理解、判断、负责。

当 AI 生成了一段看起来没问题的代码时，你能看出来它在边界情况下会崩溃；当 AI 给了你一个"标准答案"时，你能想到更好的架构；当 AI 犯错时，你能迅速定位问题，而不是束手无策。

这听起来简单，但实际上需要付出极大的自律，才能不断地投入精力来认真审查和优化 AI 输出的代码，提出“为什么这样实现”或者“是否兼容所有情况、是否会有 XX 问题”等问题，并在 AI 回答后进行适当的测试确认。

AI 现在就像一种强效毒品：服用过量会毁了你，服用过少又会让你落后于服用量更大的人。

难点在于找到平衡点、找到最适合你的量，让你在 AI 的加持下能更轻松，又不至于变得更蠢。

有个资深开发者在 Reddit 上说："对我们这种有经验的人来说，很快我们会变得像黄金一样值钱。那些只会用 AI 的所谓的“氛围程序员”们会创造出一大堆技术债务，到时候还得我们来收拾干净。"

如果你沉迷于"氛围编程"，享受那种回车键一敲 AI 都搞定的快感，却从不停下来问问自己"我真的理解这些吗"，你迟早会成为漫画里那个人。

《转型 AI 工程师》一阶段已完成：mp.weixin.qq.com/s/BcrTHliEQ…

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

今早看到 Manus 被 Meta 收购的消息，我下意识瞄了一眼浏览器侧边栏。

那里停着 Monica 我去年买了它的 Unlimited Level。这一年，眼看着它从一个小插件长成巨头争抢的资产，这种感觉很奇妙。很多人在讨论收购金额，讨论中美科技博弈。但在我这个独立开发者眼里，这不仅是一桩商业收购，更是一次对 “产品价值观” 的暴力验证。

Manus 出售前的最后一次公开复盘，含金量很高。

🎙️ 访谈对象：Manus 首席科学家 Peak (季逸超)

📺 观看地址：http://www.youtube.com

推荐理由： 完全不是印象中做个AI“套壳站”的浅层理解，逻辑密度极高。记录了从创业初期，时序上的得失与真实体感。对 AI 产品路径的判断非常犀利，值得所有 AI 创业者反复研读。强推看看，会有新启发。

01. 主角登场：从武汉光谷到硅谷焦点

为了还原这次收购的真实分量，我们需要先看清牌桌上的这三个名字。这并不是一个简单的“套壳工具”被收购的故事，而是一场惊心动魄的突围。

这两款产品背后的母公司叫 Monica.im（国内主体为武汉蝴蝶效应），创始人是肖弘。在被 Meta 收购之前，他们已经是全球 AI 应用层的顶流，典型的“墙内开花墙外香”。

• Monica（超级入口）：
  它是浏览器时代的“副驾驶”。在我的侧边栏里，它聚合了 GPT-5、Claude 4.5、Gemini 3 等所有核武器。它解决了 “输入” 的问题，帮我把全球最强的模型能力接入到我浏览的每一个网页中。


• Manus（执行代理）：
  这是真正的杀手锏。作为全球首款通用 AI 智能体，它不再是聊天，而是能独立写报告、分析数据、跨平台操作。它解决了 “执行” 的问题。


• 肖弘（CEO）：
  他不是典型的硅谷技术极客，而是一位深谙中国互联网玩法的连续创业者。早在 AI 爆发前，他就创办过“壹伴”、“微伴”等工具，是微信生态里最懂流量和社群裂变的人。

正是因为肖弘带着这种 “微信生态基因” 杀入硅谷，才有了后面让 Meta 既头疼又眼馋的增长奇迹。

02. 不是“钞能力”，是“中国式裂变”的降维打击

市面上盛传：“Manus 是因为在 Facebook 投了最多的广告，成了大金主，所以才被收购。”
大错特错。真相恰恰相反——Meta 买它，是因为它证明了自己可以“不花钱”就从 Meta 身上薅走 10 亿流量。

肖弘把我们在国内熟知的 “私域流量” 和 “裂变” 战术，完美移植到了全球市场：

• 饥饿营销： 严格的内测机制，让邀请码在二手市场炒到上千美元。


• 内容杠杆： 为了获得算力积分，用户必须生成演示视频发到社交媒体上。


• 算法回声室： 成千上万个真实用户的“惊叹帖”，骗过了 Meta 的算法，让 Meta 以为这是“有机内容”而疯狂推荐。

Meta 震惊了： 这个中国团队不需要 Meta 的销售团队，就能在 Meta 的地盘上制造病毒。扎克伯格给肖弘 VP 的位置，不是因为他懂技术，而是因为他掌握了 “如何在不烧光现金的情况下，让 10 亿用户用上 AI” 的黑魔法。

03. 不做“造物主”，做“万能接口”

作为 Monica 的重度用户。

过去这一年，技术圈总在争论“谁拥有最强的底层模型”。但这家公司证明了一件事：
不管底层模型是谁的，把能力做成普通人每天都愿意用、愿意付费的产品，才是最硬的护城河。

看看我的侧边栏：各大模型一字排开。我不需要去订阅五个不同的会员，不需要在五个网页间反复横跳。我只需要一个 Monica，就能随时调用这个星球上最强的大脑。

Meta 有 Llama，有最强的大脑，但他们缺一个能聚合所有能力、并且已经长在用户浏览器里的 “超级入口”。

如果 Meta 不买，Monica 继续做大，它就架空了底层模型厂商。收购 Monica，Meta 不仅买下了一个好用的工具，更买回了 “分发权”。

04. Llama 只有脑子，Manus 给了它“双手”

从技术维度看，Meta 的焦虑在于：Llama 只有脑子，没有手。

聊天机器人时代，用户问“怎么去东京？”，AI 给你攻略。
智能体时代，用户说“帮我订票”，AI 需要打开浏览器、登录官网、选座、支付。

Manus 的核心技术壁垒，是它为每个任务生成的云端虚拟环境。它能安全地沙盒化运行代码。

以前我需要花 2 小时去查 10 个竞品的定价并填进 Excel；现在我把任务丢给 Manus，去冲杯咖啡，回来时它已经把做好的表格发给我了。 这种 ‘从对话到交付’ 的跨越，才是 Meta 恐惧的根源。

如果未来的互联网入口是智能体，那么它在浏览网页时会自动过滤广告，只提取信息。这对靠广告生存的 Meta 是灭顶之灾。收购 Manus，本质上是一场“防御战”。 Meta 必须把这双“手”长在自己身上，重新定义“后广告时代”的商业规则。

05. 独立开发者的启示：成为“稀缺资产”，而非“外包苦力”

这对国内 AI 创业者，尤其是像我这样的独立开发者来说，其实挺提气的。

Manus 的故事告诉我们：中国团队完全可以在全球舞台上被当成 “战略资产” 买走，而不是作为廉价的“外包能力”被消耗。

我也是一人公司，我也在写代码。看着 Manus 的路径，我常在想：在独立创业黄金窗口逐渐收窄的今天，我们该怎么办？

Meta 这笔收购指明了一条新路：与其烧钱追赶巨头，不如成为他们争相购买的“稀缺资产”。

这是一种很高阶的路径设计。创业者无需与巨头在全面战争中对决，而应利用先发优势，在自己最锋利的点上——比如 Manus 的全自动执行能力——成为巨头在关键时刻唯一且急需的那块拼图。

这与个人在职场黄金期加入高速成长公司的逻辑如出一辙：

价值最大化，往往不在于你“最强”之时，而在于你“最被需要”之刻。

Manus 并没有做到 100% 的完美，初期甚至服务器不稳。但它在 Meta 最焦虑“如何让 AI 落地”的时候，它是那个 Ready 的选项。

巨头高价抢人，本质是购买 “确定性” 和 “战略时间”。

06. 结语：在“草台班子”的世界里递钥匙

很多技术人（包括我自己）常死在追求“完美”上。觉得代码不够优雅，功能不够全，不敢发布。

但现实世界往往是混乱且急迫的。

世界有时是“草台班子”——决定你市值的，不全是你的完工程度，而是你能否在巨头搭建舞台时，恰好递上他们最缺的那把钥匙。

这并非妥协，而是对时机与稀缺性的深刻理解。

与其在红海中追求绝对完美，不如在巨头战局未定的空白地带，率先做出“可用且稀缺”的产品。

“当巨头转身寻找时，你要确保自己在场，并且手里握着那把钥匙。就像肖弘在武汉光谷敲下第一行代码时，他可能也没想到，这把钥匙最终会开启硅谷的大门。但重要的是，他一直在磨那把钥匙。 ”

下面是我在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 "通用匹配 [兜底规则]";

    }

}

针对上面的测试用例及匹配结果

第一个问题及其延伸现到这，我们继续看第二个问题。

问题二

先看下面的服务器端nginx的重启命令：

# 命令一

nginx -s reload



# 命令二

systemctl reload nginx

上面两个命令都是用来重启 nginx 服务的，但是你想过它们之间有什么区别吗？哪个用起来更优雅？

答案：有区别！区别在于命令的执行方式和适用场景不同。

nginx -s reload

这是 Nginx 自带的信号控制命令:

• 直接向 Nginx 主进程发送 reload 信号


• 优雅重启:不会中断现有连接,平滑加载新配置


• 需要 nginx 命令在 PATH 环境变量中,或使用完整路径(如 /usr/sbin/nginx -s reload)


• 这是 Nginx 原生的重启方式

systemctl reload nginx

这是通过 systemd 管理的服务命令:

• 通过 systemd 管理 Nginx 服务


• 也会优雅重启 Nginx,平滑加载新配置


• 需要 systemd 环境,适用于使用 systemd 管理服务的 Linux


• 这是现代 Linux 发行版（如 CentOS 7/8, RHEL 7/8, Ubuntu 16.04+）的推荐方式。

简单一看其他相关命令对比:

• nginx -s stop 等价 systemctl stop nginx


• nginx -s quit 等价 systemctl stop nginx


• nginx -t (测试配置是否正确) - 这个没有 systemctl 对应命令

systemctl下相关常用命令：

# 设置开机自启

systemctl enable nginx



# 启动服务

systemctl start nginx



# 检查服务状态

systemctl status nginx



# 停止服务

systemctl stop nginx



# 重启服务（会中断连接）

systemctl restart nginx



# 平滑重载配置（不中断服务）-- 对应 nginx -s reload

systemctl reload nginx



# 检查配置文件语法（这是调用nginx二进制文件的功能）

nginx -t

在服务器上最优雅的使用组合：

# 先测试配置

nginx -t



# 如果配置正确,再重载

systemctl reload nginx



# 检查状态

systemctl status nginx



# 如果systemctl失败或命令不存在，则使用直接方式

sudo nginx -s reload

总结：我们不能光一脸懵的看着，哎，这两种命令都能操作nginx来, 却从来不关心它们的区别是什么？什么时候用哪个？

对于使用Linux发行版的服务端来说, 已经推荐使用 systemctl 来设置相关的nginx服务了，能使用 systemctl 就尽量使用它，因为它是现代Linux系统管理服务的标准方式。

本地开发环境或者没有 systemd 的环境下, 则可以使用 nginx 这种直接方式。

问题三

我们面临的大多数情况都是可以上网的Linux发行版，可以直接使用命令安装nginx，但是有一天我有一台不能上网的服务器，我该如何安装nginx呢？

现简单熟悉一下命令行安装nginx的步骤, Ubuntu/Debian系统为例子：

# 更新包列表

sudo apt update



# 安装 Nginx

sudo apt install nginx



# 启动 Nginx

sudo systemctl start nginx



# 设置开机自启

sudo systemctl enable nginx

上述便完成了，但是离线版安装要怎么去做呢？

因为我的服务器可能是不同的架构，比如 x86_64, ARM等等

方案一

下载官方预编译包下载地址：

x86_64 架构:

尽量使用1.24.x的版本

# 从官网下载对应系统的包

wget http://nginx.org/packages/centos/7/x86_64/RPMS/nginx-1.24.0-1.el7.ngx.x86_64.rpm

ARM64 架构:

# Ubuntu ARM64

wget http://nginx.org/packages/ubuntu/pool/nginx/n/nginx/nginx_1.24.0-1~jammy_arm64.deb

查看服务器的架构信息

# 查看当前系统架构

uname -m



# 输出示例:

# x86_64    -> Intel/AMD 64位

# aarch64   -> ARM 64位

# armv7l    -> ARM 32位



# 查看系统版本

cat /etc/os-release

把下载好的包传到服务器上，然后使用下面的命令安装：

# 对于 RPM 包 (CentOS/RHEL)

cd /tmp

sudo rpm -ivh nginx-*.rpm



# 对于 DEB 包 (Ubuntu/Debian)

cd /tmp

sudo dpkg -i nginx-*.deb

启动服务

sudo systemctl start nginx       # 启动

sudo systemctl enable nginx      # 开机自启

sudo systemctl status nginx      # 查看状态

验证

nginx -v                         # 查看版本

curl http://localhost            # 测试访问

方案二

源码编译安装的方式，一般不推荐，除非你有特殊需求，如果需要的话让后端来吧，我们是前端...,超纲了！

问题四

当有一天你使用unity 3d开发应用并导出wasm项目后，需要使用nginx部署后，当你和往常一样正常部署后，一访问发现报错误！

错误信息如下, 一般都是提示：

类似于这种：content-type ... not ... wasm

Failed to load module script: The server responded with a non-JavaScript MIME type of "application/wasm".

这时的你可能一脸懵， 我和往常一样正常的配置nginx呀，为啥别的可以，但是wasm应用报错了！为啥？

这时就引出一个不常用的知识点，我要怎么使用nginx配置wasm的应用，需要进行哪些配置？

需要配置两部分：

第一部分：配置正确的 MIME 类型

进入nginx的安装目录，找到mine.types文件，新增下面的配置：

# 新增下面类型配置

application/wasm        wasm;

第二部分：wasm的应用需要特殊配置

下面是wasm应用的配置示例，是可以直接使用的，只需要的修改一下访问文件的路径和端口即可。

server {

    listen 80;

    server_name your-domain.com;  # 修改为你的域名或ip



    # Unity WebGL 构建文件的根目录

    root /var/www/unity-webgl;

    index index.html;



    # 字符集

    charset utf-8;



    # 日志配置(可选指向特殊的日志文件)

    access_log /var/log/nginx/unity-game-access.log;

    error_log /var/log/nginx/unity-game-error.log;



    # ========== MIME 类型配置(下面配置的重点，也是区别于正常的nginx应用配置) ==========



    # WASM文件（未压缩）

    location ~ \.wasm$ {

        types {

            application/wasm wasm;

        }

        add_header Cache-Control "public, max-age=31536000, immutable";

        add_header Access-Control-Allow-Origin *;

    }



    # WASM文件（Gzip压缩）

    location ~ \.wasm\.gz$ {

        add_header Content-Encoding gzip;

        add_header Content-Type application/wasm;

        add_header Cache-Control "public, max-age=31536000, immutable";

        add_header Access-Control-Allow-Origin *;

    }



    # WASM文件（Brotli压缩）

    location ~ \.wasm\.br$ {

        add_header Content-Encoding br;

        add_header Content-Type application/wasm;

        add_header Cache-Control "public, max-age=31536000, immutable";

        add_header Access-Control-Allow-Origin *;

    }



    # Data文件（未压缩）

    location ~ \.data$ {

        types {

            application/octet-stream data;

        }

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Data文件（Gzip压缩）

    location ~ \.data\.gz$ {

        add_header Content-Encoding gzip;

        add_header Content-Type application/octet-stream;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Data文件（Brotli压缩）

    location ~ \.data\.br$ {

        add_header Content-Encoding br;

        add_header Content-Type application/octet-stream;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # JavaScript文件（未压缩）

    location ~ \.js$ {

        types {

            application/javascript js;

        }

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # JavaScript文件（Gzip压缩）

    location ~ \.js\.gz$ {

        add_header Content-Encoding gzip;

        add_header Content-Type application/javascript;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # JavaScript文件（Brotli压缩）

    location ~ \.js\.br$ {

        add_header Content-Encoding br;

        add_header Content-Type application/javascript;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Framework JS 文件

    location ~ \.framework\.js(\.gz|\.br)?$ {

        if ($uri ~ \.gz$) {

            add_header Content-Encoding gzip;

        }

        if ($uri ~ \.br$) {

            add_header Content-Encoding br;

        }

        add_header Content-Type application/javascript;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Loader JS 文件

    location ~ \.loader\.js(\.gz|\.br)?$ {

        if ($uri ~ \.gz$) {

            add_header Content-Encoding gzip;

        }

        if ($uri ~ \.br$) {

            add_header Content-Encoding br;

        }

        add_header Content-Type application/javascript;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Symbols JSON 文件

    location ~ \.symbols\.json(\.gz|\.br)?$ {

        if ($uri ~ \.gz$) {

            add_header Content-Encoding gzip;

        }

        if ($uri ~ \.br$) {

            add_header Content-Encoding br;

        }

        add_header Content-Type application/json;

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # ========== 静态资源配置(导出的wasm应用一般都有下面的静态资源) ==========



    # StreamingAssets 目录

    location /StreamingAssets/ {

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # Build 目录

    location /Build/ {

        add_header Cache-Control "public, max-age=31536000, immutable";

    }



    # TemplateData 目录（Unity 模板资源）

    location /TemplateData/ {

        add_header Cache-Control "public, max-age=86400";

    }



    # 图片文件

    location ~* \.(jpg|jpeg|png|gif|ico|svg)$ {

        add_header Cache-Control "public, max-age=2592000";

    }



    # CSS 文件

    location ~* \.css$ {

        add_header Content-Type text/css;

        add_header Cache-Control "public, max-age=2592000";

    }



    # ========== HTML 和主页面配置 ==========



    # HTML 文件不缓存（确保更新能及时生效）

    location ~ \.html$ {

        add_header Cache-Control "no-cache, no-store, must-revalidate";

        add_header Pragma "no-cache";

        add_header Expires "0";

    }



    # 根路径

    location / {

        try_files $uri $uri/ /index.html;

    }



    # ========== Gzip 压缩配置(开启gzip压缩增加访问速度) ==========



    gzip on;

    gzip_vary on;

    gzip_proxied any;

    gzip_comp_level 6;

    gzip_min_length 1024;

    gzip_types

        text/plain

        text/css

        text/xml

        text/javascript

        application/json

        application/javascript

        application/x-javascript

        application/xml

        application/xml+rss

        application/wasm

        application/octet-stream;



    # ========== 安全配置 ==========



    # 禁止访问隐藏文件

    location ~ /\. {

        deny all;

    }



    # 禁止访问备份文件

    location ~ ~$ {

        deny all;

    }



    # XSS 保护(可选配置)

    add_header X-XSS-Protection "1; mode=block";

    add_header X-Content-Type-Options "nosniff";

    add_header X-Frame-Options "SAMEORIGIN";

}

总结：

配置 wasm应用 的 Nginx 核心要点如下：

文章同步地址：http://www.liumingxin.site/blog/detail…

是的，没错。那个被人熟知的国产开源框架 Hutool 距离被卖已经过去近 7 个月了。

那 Hutool 现在的发展如何呢？它未来有哪些更新计划呢？Hutool AI 又该如何使用呢？如果不想用 Hutool 有没有可替代的框架呢？

近半年现状

从 Hutool 官网可以看出，其被卖近 7 个月内仅发布了 4 个版本更新，除了少量的新功能外，大多是 Bug 修复，当期在此期间发布了 Hutool AI 模块，算是一个里程碑式的更新：

更新日志：hutool.cn/docs/#/CHAN…

收购公司

没错，收购 Hutool 的这家公司和收购 AList 的公司是同一家公司（不够科技），该公司前段时间因为其在收购 AList 代码中悄悄收集用户设备信息，而被推向过风口浪尖，业内人士认为其收购开源框架就是为了“投毒”，所以为此让收购框架损失了很多忠实的用户。

其实，放眼望去那些 APP 公司收集用户设备和用户信息属于家常便饭了（国内隐私侵犯问题比较严重），但 AList 因为其未做文档声明，且未将收集设备信息的代码提交到公共仓库，所以大家发现之后才会比较气愤。

Hutool-AI模块使用

Hutool AI 模块的发布算是被收购之后发布的最值得让人欣喜的事了，使用它可以对接各大 AI 模型的工具模块，提供了统一的 API 接口来访问不同的 AI 服务。

目前支持 DeepSeek、OpenAI、Grok 和豆包等主流 AI 大模型。

该模块的主要特点包括：

• 统一的 API 设计，简化不同 AI 服务的调用方式。


• 支持多种主流 AI 模型服务。


• 灵活的配置方式。


• 开箱即用的工具方法。


• 一行代码调用。

具体使用如下。

1.添加依赖

<dependency>

    <groupId>cn.hutool</groupId>

    <artifactId>hutool-ai</artifactId>

    <version>5.8.38</version>

</dependency>

2.调用API

实现对话功能：

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel("your bots id").build(), DoubaoService.class);

ArrayList<Message> messages = new ArrayList<>();

messages.add(new Message("system","你是什么都可以"));

messages.add(new Message("user","你想做些什么"));

String botsChat = doubaoService.botsChat(messages);

识别图片：

//可以使用base64图片

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel(Models.Doubao.DOUBAO_1_5_VISION_PRO_32K.getModel()).build(), DoubaoService.class);

String base64 = ImgUtil.toBase64DataUri(Toolkit.getDefaultToolkit().createImage("your imageUrl"), "png");

String chatVision = doubaoService.chatVision("图片上有些什么？", Arrays.asList(base64));



//也可以使用网络图片

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel(Models.Doubao.DOUBAO_1_5_VISION_PRO_32K.getModel()).build(), DoubaoService.class);

String chatVision = doubaoService.chatVision("图片上有些什么？", Arrays.asList("https://img2.baidu.com/it/u=862000265,4064861820&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=1544"),DoubaoCommon.DoubaoVision.HIGH.getDetail());

生成视频：

//创建视频任务

DoubaoService doubaoService = AIServiceFactory.getAIService(new AIConfigBuilder(ModelName.DOUBAO.getValue()).setApiKey(key).setModel("your Endpoint ID").build(), DoubaoService.class);

String videoTasks = doubaoService.videoTasks("生成一段动画视频，主角是大耳朵图图，一个活泼可爱的小男孩。视频中图图在公园里玩耍，" +

		"画面采用明亮温暖的卡通风格，色彩鲜艳，动作流畅。背景音乐轻快活泼，带有冒险感，音效包括鸟叫声、欢笑声和山洞回声。", "https://img2.baidu.com/it/u=862000265,4064861820&fm=253&fmt=auto&app=138&f=JPEG?w=800&h=1544");

		

//查询视频生成任务信息

String videoTasksInfo = doubaoService.getVideoTasksInfo("任务id");

未来发展

• Hutool5：目前 Hutool 5.x 版本主要是基于 JDK 8 实现的，后面更新主要以 BUG 修复为准。


• Hutool6：主要以功能尝鲜为主。


• Hutool7：升级为 JDK 17，添加一些新功能，删除一些不用的类。

目前只发布了 Hutool 5.x，按照目前的更新进度来看，不知何时才能盼来 Hutool7 的发布。

同类替代框架

如果担心 Hutool 有安全性问题，或更新不及时的问题可以尝试使用同类开源工具类：

• Apache Commons：commons.apache.org/


• Google Guava：github.com/google/guav…

视频解析

http://www.bilibili.com/video/BV1QR…

小结

虽然我们不知道 Hutool 被收购意味着什么？是会变的越来越好？还是会就此陨落？我们都不知道答案，所以只能把这个问题交给时间。但从个人情感的角度出发，我希望国产开源框架越做越好。好了，我是磊哥，咱们下期见。

本文已收录到我的面试小站 http://www.javacn.site，其中包含的内容有：场景题、SpringAI、SpringAIAlibaba、并发编程、MySQL、Redis、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、JVM、设计模式、消息队列、Dify、Coze、AI常见面试题等。

我得承认，我有过很长一段时间的 技术社区上瘾。

每天上班第一件事，就是打开掘金、Hacker News、InfoQ，把热门文章刷一遍。通勤的地铁上，也要用手机看看今天又出了哪个新框架的测评、哪个Vite插件又有了更新。

我生怕错过了什么，感觉一天不刷，就会被飞速发展的技术时代抛弃。这种信息焦虑，我想很多工程师都有。

但大概从去年开始，我刻意地减少了这个仪式。我把每天早上刷文章的一小时，换成了读一些看起来和编程八竿子打不着的书。比如，心理学、经济学、历史、甚至小说。

一开始只是想换换脑子，但慢慢地，我发现，这些非技术书，反而帮我解决了很多工作中遇到的、最棘手的技术问题。

这篇文章，就是想聊聊我这个转变背后的思考。

技术的天花板

工作了五六年后，我遇到了一个很明显的瓶颈。

我发现，再多学一个JS的新语法、再多会用一个Vite插件，似乎都不能让我的能力产生质的飞跃。我的技术深度和广度，足以解决日常工作中99%的技术难题。

但我发现，工作中真正难的，往往不是技术本身。而是：

• 为什么我们团队的沟通效率这么低，一个简单的需求能来回拉扯好几天？


• 为什么这个看似简单的项目，开发过程中总是不断地范围蔓延？


• 我该如何向非技术背景的老板，证明这次重构的必要性和长期价值？


• 面对一个全新的业务，我该如何设计一个能在未来3年内，适应各种不确定性变化的技术架构？

我意识到，这些问题的答案，在MDN文档里、在Stack Overflow上，是找不到的。它们是关于人、关于系统、关于决策的复杂问题。而我当时的技术知识库，对解决这些问题，几乎毫无帮助。

我的书架，以及它们教我的事

于是，我开始漫无目的地，从技术之外的领域寻找答案。下面，我想分享几个对我影响最大的领域和书籍。

心理学，理解人

• 推荐阅读：《思考，快与慢》、《影响力》、《非暴力沟通》

作为工程师，我们习惯于和确定性的机器打交道。但我们的工作，却无时无刻不在和不确定的人打交道——用户、产品经理、同事、老板。

心理学，尤其是认知心理学，教会我理解了人性的非理性。

• 理解用户：读了《思考，快与慢》后，我开始理解为什么用户会做出那些不合逻辑的操作，为什么有时候更优的设计反而没人用。这让我在做UI/UX设计和评审时，不再只是一个技术实现者，而更能代入用户的直觉系统去思考。


• 理解同事：读了《非暴力沟通》后，我改变了我在Code Review里的沟通方式。我不再说“你这里写得不对”，而是说“我看到这个实现，我担心在XX场景下可能会有风险，你觉得呢？”。我发现，当我开始关注对方的感受和需要，而不是直接评判时，技术沟通变得顺畅了许多。

系统思考 看透架构的本质

• 推荐阅读：《第五项修炼》、《系统之美》

系统思考，教会我最重要的一个概念：世界不是由一条条独立的因果链组成的，而是由一个个相互关联的反馈回路组成的。

这个思想，彻底改变了我对软件架构的看法。

• 理解技术债：我不再把技术债看作一个孤立的坏代码问题，而是把它看作一个会自我增强的反馈回路。坏代码 -> 开发效率降低 -> Bug增多 -> 救火时间增多 -> 更没时间写好代码 -> 坏代码更多。这个循环一旦形成，不从外部打破，系统就会慢慢崩溃。


• 做出更好的技术决策：我不再追求完美的、一步到位的架构，而是去寻找那些能适应变化的、演进式的架构。我开始用机会成本去评估技术选型，用延迟和滞后效应去理解一个技术决定可能在半年后带来的影响。

历史/传记 获得古人的经验和战略

• 推荐阅读：《人类简史》、《罗马帝国衰亡史》、各种历史人物传记

历史，是研究成与败的宏大案例集。它能让你跳出眼前的一个个项目，去思考技术浪潮的更迭。

• 获得历史感 ：为什么jQuery会衰落？为什么React的Hooks范式会成功？为什么当年的AngularJS会失败？这背后，和历史上的技术革命、王朝兴衰，遵循着相似的规律——它们是否解决了当时最核心的矛盾？它们是否降低了开发成本？


• 做出更聪明的长期判断：这种历史感，让我在做一些长远的技术规划时，能更好地判断什么是真正的趋势，什么是短暂的泡沫，从而避免团队把宝贵的资源，投入到一个注定会很快消亡的技术上。

这次的分享，可能有点务虚😁，但它是我近几年最真实的感受。

程序员的工作，是把一个清晰的需求，翻译成高质量的代码。

而工程师的工作，是把一个模糊的、充满不确定性的现实世界问题，转化为一个可靠、可维护的系统。

想从程序员蜕变为工程师，需要的远不止是代码能力。

我依然每天写代码，也依然关注技术动态。但我不再焦虑于错过了哪个新库。我把更多的信心，放在了那些从非技术书籍里学来的、更底层的思维模型上。

因为我知道，这些东西，可能比我今天写的任何一行代码，都要保值得多。

你们说是不是？🙌

我得承认，我有过很长一段时间的 技术社区上瘾。

每天上班第一件事，就是打开掘金、Hacker News、InfoQ，把热门文章刷一遍。通勤的地铁上，也要用手机看看今天又出了哪个新框架的测评、哪个Vite插件又有了更新。

我生怕错过了什么，感觉一天不刷，就会被飞速发展的技术时代抛弃。这种信息焦虑，我想很多工程师都有。

但大概从去年开始，我刻意地减少了这个仪式。我把每天早上刷文章的一小时，换成了读一些看起来和编程八竿子打不着的书。比如，心理学、经济学、历史、甚至小说。

一开始只是想换换脑子，但慢慢地，我发现，这些非技术书，反而帮我解决了很多工作中遇到的、最棘手的技术问题。

这篇文章，就是想聊聊我这个转变背后的思考。

技术的天花板

工作了五六年后，我遇到了一个很明显的瓶颈。

我发现，再多学一个JS的新语法、再多会用一个Vite插件，似乎都不能让我的能力产生质的飞跃。我的技术深度和广度，足以解决日常工作中99%的技术难题。

但我发现，工作中真正难的，往往不是技术本身。而是：

• 为什么我们团队的沟通效率这么低，一个简单的需求能来回拉扯好几天？


• 为什么这个看似简单的项目，开发过程中总是不断地范围蔓延？


• 我该如何向非技术背景的老板，证明这次重构的必要性和长期价值？


• 面对一个全新的业务，我该如何设计一个能在未来3年内，适应各种不确定性变化的技术架构？

我意识到，这些问题的答案，在MDN文档里、在Stack Overflow上，是找不到的。它们是关于人、关于系统、关于决策的复杂问题。而我当时的技术知识库，对解决这些问题，几乎毫无帮助。

我的书架，以及它们教我的事

于是，我开始漫无目的地，从技术之外的领域寻找答案。下面，我想分享几个对我影响最大的领域和书籍。

心理学，理解人

• 推荐阅读：《思考，快与慢》、《影响力》、《非暴力沟通》

作为工程师，我们习惯于和确定性的机器打交道。但我们的工作，却无时无刻不在和不确定的人打交道——用户、产品经理、同事、老板。

心理学，尤其是认知心理学，教会我理解了人性的非理性。

• 理解用户：读了《思考，快与慢》后，我开始理解为什么用户会做出那些不合逻辑的操作，为什么有时候更优的设计反而没人用。这让我在做UI/UX设计和评审时，不再只是一个技术实现者，而更能代入用户的直觉系统去思考。


• 理解同事：读了《非暴力沟通》后，我改变了我在Code Review里的沟通方式。我不再说“你这里写得不对”，而是说“我看到这个实现，我担心在XX场景下可能会有风险，你觉得呢？”。我发现，当我开始关注对方的感受和需要，而不是直接评判时，技术沟通变得顺畅了许多。

系统思考 看透架构的本质

• 推荐阅读：《第五项修炼》、《系统之美》

系统思考，教会我最重要的一个概念：世界不是由一条条独立的因果链组成的，而是由一个个相互关联的反馈回路组成的。

这个思想，彻底改变了我对软件架构的看法。

• 理解技术债：我不再把技术债看作一个孤立的坏代码问题，而是把它看作一个会自我增强的反馈回路。坏代码 -> 开发效率降低 -> Bug增多 -> 救火时间增多 -> 更没时间写好代码 -> 坏代码更多。这个循环一旦形成，不从外部打破，系统就会慢慢崩溃。


• 做出更好的技术决策：我不再追求完美的、一步到位的架构，而是去寻找那些能适应变化的、演进式的架构。我开始用机会成本去评估技术选型，用延迟和滞后效应去理解一个技术决定可能在半年后带来的影响。

历史/传记 获得古人的经验和战略

• 推荐阅读：《人类简史》、《罗马帝国衰亡史》、各种历史人物传记

历史，是研究成与败的宏大案例集。它能让你跳出眼前的一个个项目，去思考技术浪潮的更迭。

• 获得历史感 ：为什么jQuery会衰落？为什么React的Hooks范式会成功？为什么当年的AngularJS会失败？这背后，和历史上的技术革命、王朝兴衰，遵循着相似的规律——它们是否解决了当时最核心的矛盾？它们是否降低了开发成本？


• 做出更聪明的长期判断：这种历史感，让我在做一些长远的技术规划时，能更好地判断什么是真正的趋势，什么是短暂的泡沫，从而避免团队把宝贵的资源，投入到一个注定会很快消亡的技术上。

这次的分享，可能有点务虚😁，但它是我近几年最真实的感受。

程序员的工作，是把一个清晰的需求，翻译成高质量的代码。

而工程师的工作，是把一个模糊的、充满不确定性的现实世界问题，转化为一个可靠、可维护的系统。

想从程序员蜕变为工程师，需要的远不止是代码能力。

我依然每天写代码，也依然关注技术动态。但我不再焦虑于错过了哪个新库。我把更多的信心，放在了那些从非技术书籍里学来的、更底层的思维模型上。

因为我知道，这些东西，可能比我今天写的任何一行代码，都要保值得多。

你们说是不是？🙌

前言

2023 年是公认的 AI 元年，2022年底OpenAI发布ChatGPT（基于GPT-3.5），2023年初迅速爆火，上线仅2个月用户突破1亿，成为历史上增长最快的消费级应用。短短三年内，AI 已经从遥不可及，进化到走进千家万户了，从只能聊天的纯语言大模型（LLMs），到今天能解决实际问题的多模态大模型（MLLMs/LMMs）、智能体（AI Agent），我们的生活正发生着不易察觉但又天翻地覆的变化。

这可能是你 2025 年看到的最真实，最中肯，也最能让你安心的文章，先说结论：程序员岗位都不会死，且未来必须具备的能力大部分人都有。

怎么看 AI 对程序员岗位的冲击

AI 的井喷式爆发，对程序员的冲击确实很大。程序员中，前端程序员最甚，在网络上，它三天一小死，五天一大死，但是结果我们也看到了，前端并没有死，甚至活得比以前更繁荣了，很多其他岗位程序员也试着用 Gemini 3 Pro 搭建了属于自己的 three.js 应用。

可能大家跟我的感觉一样，对网上前端已死的焦虑卖家并不感冒，因为在工作中，AI 给我们的感觉更像是一个老司机坐在副驾驶，我们遇到不懂的直接问它，而它也会把毕生所学毫无保留的交代出来，甚至在 VSCode Copilot 或者 Cursor 、Trae 中，我们根本不需要自己动手写代码了，80% 的时间都在 vibe coding，我们没有因为 AI 丢掉工作，反而 AI 让我们觉得：哇，太爽了，工作效率翻了三倍！

如果你有这种感觉，那么恭喜你，你是最适合在未来工作的前端开发者！

目前 AI 的局限性表现的很明显，AI 生成的代码往往 平均化、缺乏深度优化或者有隐蔽的 bug。还经常改到我们不希望变动的部分，这里祭出这张火爆全网的梗图

当然这些和 AI 还依旧不够成熟有一定关系，但是还有一个最根本的原因使得 AI 无法取代人类，它注定只能作为人类的工具，但是这个原因很哲学，请看下文。

不用怕，欲望是创造的原初动力

人类创造的起点往往是 “想做”、“喜欢”、“不爽”、“好奇”、“想证明自己” 这些内在冲动。比如 一个程序员半夜写出一个新框架，是因为“觉得现有工具太烂了，我就是要搞一个更好玩的”，而 AI 没有这些。它只有“根据训练数据预测下一个词”或者“最大化奖励函数”。我们给它一个目标，它就全力优化，但它自己永远不会“突然想”去做一件没人要求的事。

所以，AI 的“创造”其实是重组+优化过去的知识，而不是从零生出全新的渴望。

AI 很擅长在已知框架里做到极致（比如写出完美的前端组件、优化算法到最快），但人类擅长打破框架、发明新框架。这种突破往往来自 “无用” 的欲望

• 想玩 → 发明游戏


• 想偷懒 → 发明自动化工具（发明了 AI 😂）


• 想被认可 → 开源一个项目

历史上所有重大创新（互联网、智能手机、开源运动）都源于这种自发欲望。

总的来说，AI 只是现有知识最好的运用者，它无法自发的想去创造新事物（如果有的话也太可怕了，这 TM 直接天网）

要让AI拥有“真正自发的欲望”，需要解决哲学级难题：意识（consciousness） 和 主观体验（qualia）。目前科学界连“意识是什么”都没搞清楚，更别说在硅基系统里实现它了。

所以这是 AI 为什么无法代替人类的原因。

但是，从直觉上来看，AI 似乎可以替代一部分基础工作，而且现在正在发生，有些公司正在招聘高级开发者来替代多个初中级岗位...

危机真正的来源

初中级岗位确实正在慢慢消失，但这并不意味着我们在岗程序员一定会掉队，相反，我们在行业内属于 “老人”，也是最先吃到 AI 这块蛋糕的人。既然总要有人做事，所谓近水楼台先得月，最先有机会转换到 融合职责岗位 的，也会是我们这一批人，而不是其他人。

在我们这个行业，各个岗位正在发生融合，产品经理、UI、前后端的界限越来越模糊，最近还出现了所谓的 “一人公司”、“超级个体”。

初中级岗位的慢慢消失和岗位职责的融合，是 AI 时代，对普通程序员最大的挑战，我们应该顺应这一潮流，转变以往的思维，勇敢的加入到这场洪流中。

那么，该怎么做？

有解，且比以前更简单！

众所周知，T-shaped 技能模型推荐我们 先建立一个领域的深度（垂直杠），再扩展广度（水平杠），形成T形。我们很多人也是这么干的，前端同学在深刻学习 JS 语言基础、vue、react 源码，传统面试中，这些知识也是重点考察内容。

但是 AI 时代，这些技能变得非常廉价，AI已经把“深度纯技术钻研”的门槛大幅降低：它能快速生成代码、优化实现，甚至帮你读源码、总结关键。

你可以完全没读过 vue 源码，而仅用一句：“帮我实现一个 vue 的响应式系统” 实现这个功能。

T 的竖线表示领域深耕，既然深耕到一半，发现不太有竞争力了，怎么办？很简单，发展横轴，横轴代表了我们的广度（全栈狂喜），但这里说的不是纯技术广度，而是多方面多系统的融会贯通。

不过好在这些技能是我们聪明的程序员天生就具备的能力。

未来优秀程序员不再是“写代码最快的人”，而是系统思考者 + 需求翻译者 + AI指挥官 + 复杂问题解决者 + 高效沟通者。

看起来需要具备这么多能力，但是仔细想想，其实每个人都已经基本具备。每个人只需在自己的薄弱领域稍加练习即可，这比啃框架源码可简单多了，至少都是可以 “勤能补拙” 的技能。

结语

AI 不是洪水猛兽，它是我们最可靠的副驾驶，我们应该勇敢投入潮流，转变自身态度，提升视野，才能在未来的 AI 大融合时代占住自己的一席之地。

还有，2026，别感冒！

番外

• 本文章由我和 Grok 共创，对话链接：grok.com/share/c2hhc…

• Google AI Studio 帮我实现了很多想法！
  
  
  
  
  • wcnm.club/ 一个匿名的在线聊天室，可配置自己的私密 mqtt 服务器，一键启动！
  
  
  • elemental-survivor.vercel.app/ 一个肉鸽游戏，非常完整。
  
  
  • solar-max-clone-galactic-conquest.vercel.app/ 手游 《太阳系争霸战 (solarmax)》复刻
  
  
  • code-hero-pi.vercel.app/ 可以自己设计英雄的回合制卡牌对战，可联机对战！