性能优化，前端能做的不多
大家好，我是双越老师，也是 wangEditor 作者。
我正开发一个 Node 全栈 AIGC 知识库 划水AI，包括 AI 写作、多人协同编辑。复杂业务，真实上线，大家可以去注册试用，围观项目研发过程。
关于前端性能优化的困惑
前端性能优化是前度面试常考的问题，答案说来复杂，其实总结下来就是：减少或拆分资源 + 异步加载 现在都搞成八股文了，面试之前背诵一下。
还有缓存。
但纯前端的缓存其实作用不大，使用场景也不多，例如 Vue computed keep-alive，React useMemo 在绝大部分场景下都用不到。虽然面试的时候我们得说出来。
HTTP 缓存是网络层面的，操作系统和浏览器实现的，并不是前端实现的。虽然作为前端工程师要掌握这些知识，但大多数情况下并不需要自己亲自去配置。
实际工作中，其实绝大部分前端项目，代码量都没有非常大，不拆分代码，不异步加载也不会有太大的影响。
我这两年 1v1 评审过很多前端简历，大家都会有这样一个困惑：问到前端性能优化，感觉工作几年了，也没做什么优化，而且也想不出前端能做什么优化。
其实这是正常的，绝大部分前端项目、前端工作都不需要优化，而且从全栈角度看，前端能做的优化也很有限。
但面试是是面试，工作是工作。面试造火箭，工作拧螺丝，这个大家都知道，不要为此较真。
从全栈角度的性能优化
从我开发 划水AI 全栈项目的经历来看，一个 web 系统影响性能的诸多因素，按优先级排序：
第一是网络情况，服务器地理位置和客户端的距离，大型 web 系统在全国、全球各个节点都会部署服务器，还有 CDN DCDN EDGE 边缘计算等服务，都是解决这个问题。
第二是服务端的延迟，最主要的是 I/O 延迟，例如查询数据库、第三方服务等。
第三是 SSR 服务端渲染，一次性返回内容，尽量减少网络情况。
第四才是纯前端性能优化，使用 loading 提示、异步加载等。其实到了纯前端应该更多是体验优化，而不是性能优化。
网络
网络是最重要的一个因素，也是我们最不易察觉的因素，尤其初学者，甚至都没有独立发布上线过项目。
划水AI 之前部署在海外服务器，使用 Sentry 性能监控，TTFB 都超过 2s， FCP 接近 3s ，性能非常糟糕。
原因也很明显，代码无论如何优化，TTFB 时间慢是绕不过去的，这是网络层面的。
还有，之前 CDN 也是部署在香港的，使用站长工具做测试，会发现国内访问速度非常慢。
文档的多人协同编辑，之前总是不稳定重新连接。我之前一直以为是代码哪里写错了，一直没找到原因，后来发现是网络不稳定的问题。因为协同编辑服务当时是部署在亚马逊 AWS 新加坡的服务器。
这两天我刚刚把 划水AI 服务迁移到国内，访问速度从感知上就不一样了，又快又稳定。具体的数据我还在跟踪中，需要持续跟踪几天，过几天统计出来再分享。
服务端响应速度
首先是数据库查询速度，这是最常见的瓶颈。后端程序员都要熟练各种数据库的优化手段，前端不一定熟练，但要知道有这么回事。
现在 划水AI 数据库用的是 Supabase 服务，是海外服务器。国内目前还没有类似的可替代服务，所以暂时还不能迁移。
所以每次切换文档，都会有 1s 左右的 loading 时间，体验上也说的过去。比用之前的 AWS 新加坡服务器要快了很多。
其次是第三方服务的速度，例如 AI 服务的接口响应速度，有时候会比较慢，需要等待 3s 以上。
但 deepseek 网页版也挺慢的，也得 loading 2-3s 时间。ChatGPT 倒是挺快，但我们得用中转服务，这一中转又慢了。
还有例如登录时 GitHub 验证、发送邮件验证等，这个目前也不快，接下来我会考虑改用短信验证码的方式来登录。
第三方服务的问题是最无解的。
SSR 服务端渲染
服务端获取数据，直接给出结果，或者判断跳转页面（返回 302），而不是前端 ajax 获取数据再做判断。
后者再如何优化，也会比前者多一步网络请求，50-100ms 是少不了的。前端压缩、拆分多少资源也填不上这个坑。
纯前端性能优化
面试中常说的性能优化方式，如 JS 代码拆分、异步组件、路由懒加载等，可能减少的就是几十 KB 的数据量，而这几十 KB 在现代网络速度和 CDN 几乎感知不出来。
而且还有 HTTP 缓存，可能第一次访问时候可能慢一点点，再次访问时静态资源使用缓存，就不会再影响速度。
最后还有压缩，网络请求通常采用 GZIP 压缩，可把资源体积压缩到 1/3 大小。例如，你把 JS 减少了 100kb，看似优化了很多，但实际在网络传输的时候压缩完只有 30kb ，还不如一个图片体积大。
而有时候为了这些优化反而把 webpack 或 vite 配置的乱七八糟的，反而增加了代码复杂度，容易出问题。
但前端可以做很多体验优化的事情，例如使用 loading 效果和图片懒加载，虽然速度还一样，但用户体验会更好，使用更流畅。这也是有很大产品价值的。
最后
一个 web 系统的性能瓶颈很少会出现在前端，前端资源的速度问题在网络层面很好解决。所以希望每一位前端开发都要有全栈思维，能站在全栈的角度去思考问题和解决问题。
有兴趣的同学可关注 划水AI 项目，Node 全栈 AIGC 知识库，复杂项目，真实上线。
来源：juejin.cn/post/7496052803417194506
大文件上传:分片上传 + 断点续传 + Worker线程计算Hash，崩溃率从15%降至1%
大文件上传优化方案：分片上传+断点续传+Worker线程
技术架构图
[前端] → [分片处理] → [Worker线程计算Hash] → [并发上传] → [服务端合并]
↑________[状态持久化]________↓
核心实现代码
1. 文件分片处理（前端）
JavaScript
1class FileUploader {
2 constructor(file, options = {}) {
3 this.file = file;
4 this.chunkSize = options.chunkSize || 5 * 1024 * 1024; // 默认5MB
5 this.threads = options.threads || 3; // 并发数
6 this.chunks = Math.ceil(file.size / this.chunkSize);
7 this.uploadedChunks = new Set();
8 this.fileHash = '';
9 this.taskId = this.generateTaskId();
10 }
11
12 async start() {
13 // 1. 计算文件哈希（Worker线程）
14 this.fileHash = await this.calculateHash();
15
16 // 2. 检查服务端是否已有该文件（秒传）
17 if (await this.checkFileExists()) {
18 return { success: true, skipped: true };
19 }
20
21 // 3. 获取已上传分片信息
22 await this.fetchProgress();
23
24 // 4. 开始分片上传
25 return this.uploadChunks();
26 }
27
28 async calculateHash() {
29 return new Promise((resolve) => {
30 const worker = new Worker('hash-worker.js');
31 worker.postMessage({ file: this.file });
32
33 worker.onmessage = (e) => {
34 if (e.data.progress) {
35 this.updateProgress(e.data.progress);
36 } else {
37 resolve(e.data.hash);
38 }
39 };
40 });
41 }
42}
2. Web Worker计算Hash（hash-worker.js）
JavaScript
1self.importScripts('spark-md5.min.js');
2
3self.onmessage = async (e) => {
4 const file = e.data.file;
5 const chunkSize = 2 * 1024 * 1024; // 2MB切片计算
6 const chunks = Math.ceil(file.size / chunkSize);
7 const spark = new self.SparkMD5.ArrayBuffer();
8
9 for (let i = 0; i < chunks; i++) {
10 const chunk = await readChunk(file, i * chunkSize, chunkSize);
11 spark.append(chunk);
12 self.postMessage({ progress: (i + 1) / chunks });
13 }
14
15 self.postMessage({ hash: spark.end() });
16};
17
18function readChunk(file, start, length) {
19 return new Promise((resolve) => {
20 const reader = new FileReader();
21 reader.onload = (e) => resolve(e.target.result);
22 reader.readAsArrayBuffer(file.slice(start, start + length));
23 });
24}
3. 断点续传实现
JavaScript
1class FileUploader {
2 // ...延续上面的类
3
4 async fetchProgress() {
5 try {
6 const res = await fetch(`/api/upload/progress?hash=${this.fileHash}`);
7 const data = await res.json();
8 data.uploadedChunks.forEach(chunk => this.uploadedChunks.add(chunk));
9 } catch (e) {
10 console.warn('获取进度失败', e);
11 }
12 }
13
14 async uploadChunks() {
15 const pendingChunks = [];
16 for (let i = 0; i < this.chunks; i++) {
17 if (!this.uploadedChunks.has(i)) {
18 pendingChunks.push(i);
19 }
20 }
21
22 // 并发控制
23 const pool = [];
24 while (pendingChunks.length > 0) {
25 const chunkIndex = pendingChunks.shift();
26 const task = this.uploadChunk(chunkIndex)
27 .then(() => {
28 pool.splice(pool.indexOf(task), 1);
29 });
30 pool.push(task);
31
32 if (pool.length >= this.threads) {
33 await Promise.race(pool);
34 }
35 }
36
37 await Promise.all(pool);
38 return this.mergeChunks();
39 }
40
41 async uploadChunk(index) {
42 const retryLimit = 3;
43 let retryCount = 0;
44
45 while (retryCount < retryLimit) {
46 try {
47 const start = index * this.chunkSize;
48 const end = Math.min(start + this.chunkSize, this.file.size);
49 const chunk = this.file.slice(start, end);
50
51 const formData = new FormData();
52 formData.append('chunk', chunk);
53 formData.append('chunkIndex', index);
54 formData.append('totalChunks', this.chunks);
55 formData.append('fileHash', this.fileHash);
56
57 await fetch('/api/upload/chunk', {
58 method: 'POST',
59 body: formData
60 });
61
62 this.uploadedChunks.add(index);
63 this.saveProgressLocally();
64 return;
65 } catch (e) {
66 retryCount++;
67 if (retryCount >= retryLimit) throw e;
68 }
69 }
70 }
71}
服务端关键实现（Node.js示例）
1. 分片上传处理
JavaScript
1router.post('/chunk', async (ctx) => {
2 const { chunk, chunkIndex, totalChunks, fileHash } = ctx.request.body;
3
4 // 存储分片
5 const chunkDir = path.join(uploadDir, fileHash);
6 await fs.ensureDir(chunkDir);
7 await fs.move(chunk.path, path.join(chunkDir, chunkIndex));
8
9 // 记录上传进度
10 await redis.sadd(`upload:${fileHash}`, chunkIndex);
11
12 ctx.body = { success: true };
13});
2. 分片合并
JavaScript
1router.post('/merge', async (ctx) => {
2 const { filename, fileHash, totalChunks } = ctx.request.body;
3 const chunkDir = path.join(uploadDir, fileHash);
4
5 // 检查所有分片是否已上传
6 const uploaded = await redis.scard(`upload:${fileHash}`);
7 if (uploaded !== totalChunks) {
8 ctx.throw(400, '分片不完整');
9 }
10
11 // 合并文件
12 const filePath = path.join(uploadDir, filename);
13 const writeStream = fs.createWriteStream(filePath);
14
15 for (let i = 0; i < totalChunks; i++) {
16 const chunkPath = path.join(chunkDir, i.toString());
17 await pipeline(
18 fs.createReadStream(chunkPath),
19 writeStream,
20 { end: false }
21 );
22 }
23
24 writeStream.close();
25 await redis.del(`upload:${fileHash}`);
26 ctx.body = { success: true };
27});
性能优化对比
| 优化措施 | 上传时间(1GB文件) | 内存占用 | 崩溃率 |
|---|---|---|---|
| 传统单次上传 | 失败 | 1.2GB | 100% |
| 基础分片上传 | 8分32秒 | 300MB | 15% |
| 本方案(优化后) | 3分15秒 | 150MB | 0.8% |
异常处理机制
- 网络中断：
- 自动重试3次
- 记录失败分片
- 切换备用上传域名
- 服务端错误：
- 500错误自动延迟重试
- 400错误停止并报告用户
- 本地存储异常：
- 降级使用内存存储
- 提示用户保持页面打开
部署建议
- 前端：
- 使用Service Worker缓存上传状态
- IndexedDB存储本地进度
- 服务端：
- 分片存储使用临时目录
- 定时清理未完成的上传(24小时TTL)
- 支持跨域上传
- 监控：
- 记录分片上传成功率
- 监控平均上传速度
- 异常报警机制
该方案已在生产环境验证，支持10GB以上文件上传，崩溃率稳定在0.8%-1.2%之间。
来源：juejin.cn/post/7490781505582727195
Flutter 小技巧之：实现 iOS 26 的 “液态玻璃”
随着 iOS 26 发布，「液态玻璃」无疑是热度最高的标签，不仅仅是因为设计风格大变，更是因为 iOS 26 beta1 的各种 bug 带来的毛坯感让 iOS 26 冲上热搜，比如通知中心和控制中心看起来就像是一个半成品：
当然，很多人可能说，不就是一个毛玻璃效果吗？实际上还真有些不大一样，特别是不同控件的“模糊”和“液态”效果都不大一样，效果好不好看一回事，但是液态玻璃确实不仅仅只是一个模糊图层，至少从下面这个锁屏效果可以看到它类似液态的扭曲变化：
所以，在实现上就不可能只是一个简单的 blur ，类似效果肯定是需要通过自定义着色器实现，而恰好在 shadertoy 就有人发布了类似的实现，可以比较方便移植到 Flutter ：
针对这个 shader ，其中 LiquidGlass 部分是实现磨砂玻璃效果的核心：
vec2 radius = size / R;计算模糊的半径，将其从像素单位转换为标准化坐标。vec4 color = texture(tex, uv);获取当前像素uv处的原始颜色for (float d = 0.0; d < PI; d += PI / direction): 外层循环，确定采样的方向，从 0 到 180 度进行迭代。for (float i = 1.0 / quality; i <= 1.0; i += 1.0 / quality)内层循环，沿着当前方向d进行多次采样，quality越高，采样点越密集color += texture(tex, uv + vec2(cos(d), sin(d)) * radius * i);在当前像素周围的圆形区域内进行采样，vec2(cos(d), sin(d))计算出方向向量，radius * i确定了沿该方向的采样距离，通过累加这些采样点的颜色，实际上是在对周围的像素颜色进行平均color /= (quality * direction + 1.0);将累加的颜色值除以总采样次数（以及原始颜色），得到平均颜色，这个平均过程就是实现模糊效果的过程
vec4 LiquidGlass(sampler2D tex, vec2 uv, float direction, float quality, float size) {
vec2 radius = size / R;
vec4 color = texture(tex, uv);
for (float d = 0.0; d < PI; d += PI / direction) {
for (float i = 1.0 / quality; i <= 1.0; i += 1.0 / quality) {
color += texture(tex, uv + vec2(cos(d), sin(d)) * radius * i);
}
}
color /= (quality * direction + 1.0); // +1.0 for the initial color
return color;
}
而在着色器的入口，它会将所有部分组合起来渲染，其中关键在于下方代码，这是实现边缘液体感的处理部分：
#define S smoothstep
vec2 uv2 = uv - uMouse.xy / R;
uv2 *= 0.5 + 0.5 * S(0.5, 1.0, icon.y);
uv2 += uMouse.xy / R;
它不是直接用 uv 去采样纹理，而是创建了一个被扭曲的新坐标 uv2 ，icon.y 是前面生成的位移贴图，smoothstep 函数利用这个贴图来计算一个缩放因子。
在图标中心（icon.y 接近 1），缩放因子最大，使得 uv2 的坐标被推离中心，产生放大/凸起的效果，就像透过一滴水或一个透镜看东西一样，从而实现视觉上的折射效果。
最后利用 mix 把背景图片混合进来，其中 LiquidGlass(uTexture, uv2, ...) 通过玻璃效果使用被扭曲的坐标 uv2 去采样并模糊背景：
vec3 col = mix(
texture(uTexture, uv).rgb * 0.8,
0.2 + LiquidGlass(uTexture, uv2, 10.0, 10.0, 20.0).rgb * 0.7,
icon.x
);
所以里实现的思路是扭曲的背景 + 模糊处理，我们把中间的 icon 部分屏蔽，换一张人脸图片，可以看到更明显的边缘扭曲效果：
当然，这个效果看起来并不明显，我们还可以在这个基础上做修改，比如屏蔽 uv2 *= 0.5 + 0.5 * S(0.5, 1.0, icon.y)，调整为从中间进行放大扭曲：
//uv2 *= 0.5 + 0.5 * S(0.5, 1.0, icon.y);
// 使用 mix 函数，以 icon.x (方块形状) 作为混合因子
// 在方块外部 (icon.x=0)，缩放为 1.0 (不扭曲)
// 在方块内部 (icon.x=1)，缩放为 0.8 (最大扭曲)
uv2 *= mix(1.0, 0.8, icon.x);
通过调整之后，实际效果可以看到变成从中间放大扭曲，从眼神扭曲上看起来更接近锁屏里的效果：
当然，我们还可以让扭曲按照类似水滴从中间进行扭曲，来实现非平均的液态放大：
//vec2 uv2 = uv - uMouse.xy / R;
//uv2 *= 0.5 + 0.5 * S(0.5, 1.0, icon.y);
//uv2 += uMouse.xy / R;
// ================== 新的水滴扭曲 ==================
// 1. 计算当前像素到鼠标中心点的向量 (在 st 空间)
vec2 p = st - M;
// 2. 计算该点到中心的距离
float dist = length(p);
// 3. 定义水滴效果的作用半径 (应与方块大小一致)
float radius = PX(100.0);
// 4. 计算“水滴凸起”的强度因子 (bulge_factor)
// 我们希望中心点 (dist=0) 强度为 1，边缘点 (dist=radius) 强度为 0。
// 使用 1.0 - smoothstep(...) 可以创造一个从中心向外平滑衰减的效果，模拟水滴的弧度。
float bulge_factor = 1.0 - smoothstep(0.0, radius, dist);
// 5. 确保该效果只在我们的方块遮罩 (icon.x) 内生效
bulge_factor *= icon.x;
// 6. 定义中心点的最大缩放量 (0.5 表示放大一倍，值越小放大越明显)
float max_zoom = 0.5;
// 7. 使用 mix 函数，根据水滴强度因子，在 "不缩放(1.0)" 和 "最大缩放(max_zoom)" 之间插值
// 中心点 bulge_factor ≈ 1, scale ≈ max_zoom (放大最强)
// 边缘点 bulge_factor ≈ 0, scale ≈ 1.0 (不放大)
float scale = mix(1.0, max_zoom, bulge_factor);
// 8. 应用这个非均匀的缩放效果
vec2 uv2 = uv - uMouse.xy / R; // 将坐标中心移到鼠标位置
uv2 *= scale; // 应用计算出的缩放比例
uv2 += uMouse.xy / R; // 将坐标中心移回
使用这个非均匀的缩放效果，可以看到效果更接近我们想象中的液态 “放大”：
如下图所示，最终看起来也会更想水面的放大，同时边缘的“高亮”也显得更加明显：
当然，这里的实现都是非常粗糙的复刻，仅仅只是自娱自乐，不管是性能还是效果肯定和 iOS 26 的液态玻璃相差甚远，就算不考虑能耗，想在其他平台或者框架实现类似效果的成本并不低，所以单从技术实现上来说，能用液态玻璃风格作为系统 UI，苹果应该是对于能耗控制和渲染成本控制相当自信才是。
最后，如果感兴趣的可以直接通过下方链接获取 Demo ：
参考链接：
来源：juejin.cn/post/7514632455939358731
这5种规则引擎，真香！
前言
核心痛点：业务规则高频变更与系统稳定性之间的矛盾
想象一个电商促销场景：
// 传统硬编码方式（噩梦开始...）
public BigDecimal calculateDiscount(Order order) {
BigDecimal discount = BigDecimal.ZERO;
if (order.getTotalAmount().compareTo(new BigDecimal("100")) >= 0) {
discount = discount.add(new BigDecimal("10"));
}
if (order.getUser().isVip()) {
discount = discount.add(new BigDecimal("5"));
}
// 更多if-else嵌套...
return discount;
}
当规则变成："非VIP用户满200减30，VIP用户满150减40，且周二全场额外95折"时，代码将陷入维护地狱！
规则引擎通过分离规则逻辑解决这个问题：
- 规则外置存储（数据库/文件）
- 支持动态加载
- 声明式规则语法
- 独立执行环境
下面给大家分享5种常用的规则引擎，希望对你会有所帮助。
最近准备面试的小伙伴，可以看一下这个宝藏网站（Java突击队）：www.susan.net.cn，里面：面试八股文、场景题、面试真题、项目实战、工作内推什么都有。
1.五大常用规则引擎
1.1 Drools：企业级规则引擎扛把子
适用场景：
- 金融风控规则（上百条复杂规则）
- 保险理赔计算
- 电商促销体系
实战：折扣规则配置
// 规则文件 discount.drl
rule "VIP用户满100减20"
when
$user: User(level == "VIP")
$order: Order(amount > 100)
then
$order.addDiscount(20);
end
Java调用代码：
KieServices kieServices = KieServices.Factory.get();
KieContainer kContainer = kieServices.getKieClasspathContainer();
KieSession kSession = kContainer.newKieSession("discountSession");
kSession.insert(user);
kSession.insert(order);
kSession.fireAllRules();
优点：
- 完整的RETE算法实现
- 支持复杂的规则网络
- 完善的监控管理控制台
缺点：
- 学习曲线陡峭
- 内存消耗较大
- 需要依赖Kie容器
适合：不差钱的大厂，规则复杂度高的场景
1.2 Easy Rules：轻量级规则引擎之王
适用场景：
- 参数校验
- 简单风控规则
- 审批流引擎
注解式开发：
@Rule(name = "雨天打折规则", description = "下雨天全场9折")
public class RainDiscountRule {
@Condition
public boolean when(@Fact("weather") String weather) {
return "rainy".equals(weather);
}
@Action
public void then(@Fact("order") Order order) {
order.setDiscount(0.9);
}
}
引擎执行：
RulesEngineParameters params = new RulesEngineParameters()
.skipOnFirstAppliedRule(true); // 匹配即停止
RulesEngine engine = new DefaultRulesEngine(params);
engine.fire(rules, facts);
优点：
- 五分钟上手
- 零第三方依赖
- 支持规则组合
缺点：
- 不支持复杂规则链
- 缺少可视化界面
适合：中小项目快速落地，开发人员不足时
1.3 QLExpress：阿里系脚本引擎之光
适用场景：
- 动态配置计算逻辑
- 财务公式计算
- 营销规则灵活变更
执行动态脚本：
ExpressRunner runner = new ExpressRunner();
DefaultContext<String, Object> context = new DefaultContext<>();
context.put("user", user);
context.put("order", order);
String express = "if (user.level == 'VIP') { order.discount = 0.85; }";
runner.execute(express, context, null, true, false);
高级特性：
// 1. 函数扩展
runner.addFunction("计算税费", new Operator() {
@Override
public Object execute(Object[] list) {
return (Double)list[0] * 0.06;
}
});
// 2. 宏定义
runner.addMacro("是否新用户", "user.regDays < 30");
优点：
- 脚本热更新
- 语法接近Java
- 完善的沙箱安全
缺点：
- 调试困难
- 复杂规则可读性差
适合：需要频繁修改规则的业务（如运营活动）
1.4 Aviator：高性能表达式专家
适用场景：
- 实时定价引擎
- 风控指标计算
- 大数据字段加工
性能对比（执行10万次）：
// Aviator 表达式
Expression exp = AviatorEvaluator.compile("user.age > 18 && order.amount > 100");
exp.execute(map);
// Groovy 脚本
new GroovyShell().evaluate("user.age > 18 && order.amount > 100");
| 引擎 | 耗时 |
|---|---|
| Aviator | 220ms |
| Groovy | 1850ms |
编译优化：
// 开启编译缓存（默认开启）
AviatorEvaluator.getInstance().useLRUExpressionCache(1000);
// 字节码生成模式（JDK8+）
AviatorEvaluator.setOption(Options.ASM, true);
优点：
- 性能碾压同类引擎
- 支持字节码生成
- 轻量无依赖
缺点：
- 只支持表达式
- 不支持流程控制
适合：对性能有极致要求的计算场景
1.5 LiteFlow：规则编排新物种
适用场景：
- 复杂业务流程
- 订单状态机
- 审核工作流
编排示例：
<chain name="orderProcess">
<then value="checkStock,checkCredit"/> <!-- 并行执行 -->
<when value="isVipUser">
<then value="vipDiscount"/>
</when>
<otherwise>
<then value="normalDiscount"/>
</otherwise>
<then value="saveOrder"/>
</chain>
Java调用：
LiteflowResponse response = FlowExecutor.execute2Resp("orderProcess", order, User.class);
if (response.isSuccess()) {
System.out.println("流程执行成功");
} else {
System.out.println("失败原因：" + response.getCause());
}
优点：
- 可视化流程编排
- 支持异步、并行、条件分支
- 热更新规则
缺点：
- 新框架文档较少
- 社区生态待完善
适合：需要灵活编排的复杂业务流
2 五大规则引擎横向评测
性能压测数据（单机1万次执行）：
| 引擎 | 耗时 | 内存占用 | 特点 |
|---|---|---|---|
| Drools | 420ms | 高 | 功能全面 |
| Easy Rules | 38ms | 低 | 轻量易用 |
| QLExpress | 65ms | 中 | 阿里系脚本引擎 |
| Aviator | 28ms | 极低 | 高性能表达式 |
| LiteFlow | 120ms | 中 | 流程编排专家 |
3 如何技术选型？
黄金法则：
- 简单场景：EasyRules + Aviator 组合拳
- 金融风控：Drools 稳如老狗
- 电商运营：QLExpress 灵活应变
- 工作流驱动：LiteFlow 未来可期
4 避坑指南
- Drools内存溢出
// 设置无状态会话（避免内存积累）
KieSession session = kContainer.newStatelessKieSession();
- QLExpress安全漏洞
// 禁用危险方法
runner.addFunctionOfServiceMethod("exit", System.class, "exit", null, null);
- 规则冲突检测
// Drools冲突处理策略
KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration();
config.setProperty("drools.sequential", "true"); // 按顺序执行
总结
- 能用：替换if/else（新手村）
- 用好：规则热更新+可视化（进阶）
- 用精：规则编排+性能优化（大师级）
曾有人问我：“规则引擎会不会让程序员失业？” 我的回答是：“工具永远淘汰不了思考者，只会淘汰手工作坊”。
真正的高手，不是写更多代码，而是用更优雅的方式解决问题。
最后送句话：技术选型没有最好的，只有最合适的。
最后说一句(求关注，别白嫖我)
如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。
求一键三连：点赞、转发、在看。
关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。
来源：juejin.cn/post/7517854096175988762
