😡同事查日志太慢，我现场教他一套 grep 组合拳！
前言
最近公司来了个新同事，年轻有活力，就是查日志的方式让我有点裂开。
事情是这样的：他写的代码在测试环境报错了，报警信息也被钉钉机器人发到了我们群里。作为资深摸鱼战士，我寻思正好借机摸个鱼顺便指导一下新人，就凑过去看了眼。
结果越看我越急，差点当场喊出：“兄弟你是来写代码的，还是和日志谈恋爱的？”
来看看他是怎么查日志的
他先敲了一句：
tail -f a.log | grep "java.lang.NullPointerException"
想着等下次报错就能立刻看到。等了半天，终于蹦出来一行：
2025-07-03 11:38:48.339 [http-nio-8960-exec-1] [47gK4n32jEYvTYX8AYti48] [INFO] [GlobalExceptionHandler] java.lang.NullPointerException, ex: java.lang.NullPointerException
java.lang.NullPointerException: null
我提醒他：“这样看不到堆栈信息啊。”
他“哦”了一声，灵机一动，用 vi把整个文件打开，/NullPointerException 搜关键词，一个 n 一个 n 地翻……半分钟过去了，异常在哪都没找全，我都快给他跪下了。
于是我当场掏出了一套我压箱底的“查日志组合拳”，一招一式手把手教他。他当场就“悟了”，连连称妙，并表示想让我写成文章好让他发给他前同事看——因为他前同事也是这样查的……
现在，这套组合拳我也分享给你，希望你下次查日志的时候，能让你旁边的同事开开眼。
正式教学
核心的工具其实还是 grep 命令，下面我将分场景给你讲讲我的实战经验，保证你能直接套用！
场景一：查异常堆栈，不能只看一行！
Java 异常堆栈通常都是多行的，仅仅用 grep "NullPointerException" 只能看到最上面那一行，问题根源在哪你压根找不到。
这时候使用 **grep** 的 **-A** (After) 参数来显示匹配行之后的N行。
# 查找 NullPointerException，并显示后面 50 行
grep -A 50 "java.lang.NullPointerException" a.log
如果你发现异常太多，屏幕一闪而过，也可以用less加上分页查看：
grep -A 50 "java.lang.NullPointerException" a.log | less
在 less 视图中，你可以：
- 使用 箭头↑↓ 或 Page Up/Down 键来上下滚动
- 输入
G直接翻到末尾，方便快速查看最新的日志 - 输入
/Exception继续搜索 - 按
q键退出
这样你就能第一时间拿到完整异常上下文信息，告别反复 vi + / 的低效操作！
场景二：实时看新日志怎么打出来的
如果你的应用正在运行，并且你怀疑它会随时抛出异常，你可以实时监控日志文件的增长。
使用 tail -f 结合 grep：
# 实时监控 a.log 文件的新增内容，并只显示包含 "java.lang.NullPointerException" 的行及其后50行
tail -f a.log | grep -A 50 "java.lang.NullPointerException"
只要异常一出现，它就会自动打出来，堆栈信息也一并送到你面前！
- 想停下？
Ctrl + C - 想更准确？加
-i忽略大小写，防止大小写拼错找不到
场景三：翻历史日志 or 查压缩日志
服务器上的日志一般都会按天或按大小分割并压缩，变成 .log.2025-07-02.gz 这种格式，查找这些文件的异常信息怎么办？
🔍 查找当前目录所有 .log 文件：
# 在当前目录下查找所有以 .log 结尾的文件，-H 参数可以顺便打印出文件名
grep -H -A 50 "java.lang.NullPointerException" *.log
其中 -H 会帮你打印出是哪个文件中出现的问题，防止你找完还不知道是哪天的事。
🔍 查找 .gz 文件（压缩日志）：
zgrep -H -A 50 "java.lang.NullPointerException" *.gz
zgrep 是专门处理 .gz 的 grep，它的功能和 grep 完全一样，无需手动解压，直接开整！
场景四：统计异常数量（快速判断异常是否频繁）
有时候你需要知道某个异常到底出现了多少次，是偶发还是成灾，使用 grep -c（count）：
grep -c "java.lang.NullPointerException" a.log
如果你要统计所有日志里的数量：
grep -c "java.lang.NullPointerException" *.log
其他常用的 grep 参数
| 参数 | 作用 |
|---|---|
-B N | 匹配行之前的 N 行（Before） |
-A N | 匹配行之后的 N 行（After） |
-C N | 匹配行上下共 N 行（Context） |
-i | 忽略大小写 |
-H | 显示匹配的文件名 |
-r | 递归搜索目录下所有文件 |
比如：
grep -C 25 "java.lang.NullPointerException" a.log
这个命令就能让你一眼看到异常前后的上下文，帮助定位代码逻辑是不是哪里先出问题了。
尾声
好了，这套组合拳我已经传授给你了，要是别人问你在哪学的，记得报我杆师傅的大名（doge）。
其实还有其他查日志的工具，比如awk、wc 等。
但是我留了一手，没有全部教给我这个同事，毕竟江湖规则，哪有一出手就把看家本领全都交出去的道理？
如果你也想学，先拜个师交个学费（点赞、收藏、关注），等学费凑够了，我下次再开新课，传授给大家~
来源：juejin.cn/post/7524216834619408430
为什么我不再相信 Tailwind？三个月重构项目教会我的事
Tailwind 曾经是我最爱的工具，直到它让我维护不下去整个项目。
前情提要：我是如何变成 Tailwind 重度用户的
作为一个多年写 CSS 的前端，我曾经深陷“命名地狱”：
什么 .container-title, .btn-primary, .form-item-error，一个项目下来能写几百个类名，然后改样式时不知道该去哪动刀，甚至删个类都心慌。
直到我遇见了 Tailwind CSS——一切原子化，想改样式就加 class，别管名字叫什么，直接调属性即可。
于是我彻底拥抱它，团队项目里我把所有 SCSS 全部清除，组件中也只保留了 Tailwind class，一切都干净、轻便、高效。
但故事从这里开始转变。
三个月后的重构期，我被 Tailwind“反噬”
我们的后台管理系统迎来一次大版本升级，我负责重构 UI 样式逻辑，目标是：
- 统一设计规范；
- 提高代码可维护性；
- 降低多人协作时的样式冲突。
刚开始我信心满满，毕竟 Tailwind 提供了：
- 原子化 class；
@apply合成组件级 class；- 配置主题色/字体/间距系统；
- 插件支持动画/form 控件/typography；
但随着项目深入，我开始发现 几个巨大的问题，并最终决定停用 Tailwind。
一、class 污染：结构和样式纠缠成灾
来看一个真实例子：
<div class="flex items-center justify-between bg-white p-4 rounded-lg shadow-sm border border-gray-200">
<h2 class="text-lg font-semibold text-gray-800">订单信息</h2>
<button class="text-sm px-2 py-1 bg-blue-500 text-white rounded hover:bg-blue-600">编辑</button>
</div>
你能看出这个组件的“设计意图”吗？
你能快速改它的样式吗？
一个看似简单的按钮，一眼看不到设计语言，只看到一坨 class，你根本不知道：
px-2 py-1是从哪里决定的？bg-blue-500是哪个品牌色？hover:bg-blue-600是统一交互吗？
Tailwind 让样式变得快，但也让样式“变得不可读”。
二、复用失败：想复用样式还得靠 SCSS
我天真地以为 @apply 能帮我合成组件级样式，比如：
.btn-primary {
@apply text-white bg-blue-500 px-4 py-2 rounded;
}
但问题来了：
@apply不能用在媒体查询内；@apply不支持复杂嵌套、hover/focus 的组合；- 响应式、伪类写在 HTML 里更乱，如：
lg:hover:bg-blue-700； - 没法动态拼接 class，逻辑和样式混在组件逻辑层了。
最终结果就是：复用失败、样式重复、维护困难。
三、设计规范无法沉淀
我们设计系统中定义了若干基础变量：
- 主色：
#0052D9 - 次色：
#A0AEC0 - 字体尺寸规范：
12/14/16/18/20/24/32px - 组件间距：
8/16/24
本来我们希望 Tailwind 的 theme.extend 能承载这套设计系统，结果发现：
- tailwind.config.js 修改后，需要全员重启 dev server；
- 新增设计 token 非常繁琐，不如直接写 SCSS 变量；
- 多人改配置时容易冲突；
- 和设计稿同步代价高。
这让我明白：配置式设计系统不适合快速演进的产品团队。
四、多人协作混乱：Tailwind 并不直观
当我招了一位新同事，给他一个组件代码时，他的第一句话是：
“兄弟，这些 class 是从设计稿复制的吗？”
他根本看不懂 gap-6, text-gray-700, tracking-wide 分别是什么意思，只看到一堆“魔法 class” 。
更糟糕的是，每个人心中对 text-sm、text-base 的视觉认知不同，导致多个组件在微调时出现样式不一致、间距不统一的问题。
Tailwind 的语义脱离了设计意图，协作就失去了基础。
最终决定：我切回了 SCSS + BEM + 设计 token
我们开始回归传统模式：
- 所有组件都有独立
.scss文件； - 使用 BEM 命名规范：
.button,.button--primary,.button--disabled； - 所有颜色/间距/字体等统一放在
_variables.scss中； - 每个组件样式文件都注释设计规范来源。
这种模式虽然看起来“原始”，但它：
- 清晰分离结构和样式；
- 强制大家遵守设计规范；
- 组件样式可复用，可继承，可重写；
- 新人一眼看懂，不需要会 Tailwind 语法。
总结：Tailwind 不是错，是错用的代价太高
Tailwind 在以下场景表现极好：
- 个人项目 / 小程序：快速开发、无需复用；
- 组件库原型：试验颜色、排版效果；
- 纯前端工程师独立开发的项目：没有协作负担。
但在以下情况，Tailwind 会成为维护灾难：
- 多人协作；
- UI 不断迭代，设计语言需频繁调整；
- 有强复用需求（组件抽象）；
- 与设计系统严格对齐的场景；
我为什么写这篇文章？
不是为了黑 Tailwind，而是为了让你在选择技术栈时更慎重。
就像当年我们争论 Sass vs Less，今天的 Tailwind vs 原子/语义 CSS 并没有标准答案。
Tailwind 很强，但不是所有团队都适合。
也许你正在享受它的爽感，但三个月后你可能会像我一样，把所有 .w-full h-screen text-gray-800 替换成 .layout-container。
尾声：如果你非要继续用 Tailwind，我建议你做这几件事
- 强制使用
@apply形成组件级 class，不允许直接使用长串 class； - 抽离公共样式，写在一个统一的组件样式文件中；
- 和设计团队对齐 Tailwind 的 spacing/font/color；
- 用 tailwind.config.js 做好 token 映射和语义名设计；
- 每个页面都进行 CSS code review，不然很快就会变垃圾堆。
来源：juejin.cn/post/7511602231508664361
用了十年 Docker，我为什么决定换掉它？
一、Docker 不再万能，我们该何去何从？
过去十年，Docker 改变了整个软件开发世界。它以“一次构建，到处运行”的理念，架起了开发者和运维人员之间的桥梁，推动了 DevOps 与微服务架构的广泛落地。
从自动化部署、持续集成到快速交付，Docker 一度是不可或缺的技术基石。
然而到了 2025 年，越来越多开发者开始重新审视 Docker。
系统规模在不断膨胀，开发场景也更加多元，不再是当初以单一后端应用为主的架构。
如今，开发者面临的不只是如何部署一个服务，更要关注架构的可扩展性、容器的安全性、本地与云端的适配性，以及资源的最优利用。
在这种背景下，Docker 开始显得不再那么“全能”，它在部分场景下的臃肿、安全隐患和与 Kubernetes 的解耦问题，使得不少团队正在寻找更轻、更适合自身的替代方案。
之所以写下这篇文章就是为了帮助你认清 Docker 当前的局限，了解新的技术趋势，并发现适用于不同场景的下一代容器化工具。
二、Docker 的贡献与瓶颈
不可否认，Docker 曾是容器化革命的引擎。从过去到现在，它的最大价值在于降低了环境配置的复杂度，让开发与运维团队之间的协作更加顺畅，带动了整个容器生态的发展。
很多团队正是依赖 Docker 才实现了快速构建镜像、构建流水线、部署微服务的能力。
但与此同时，Docker 本身也逐渐显露出局限性。比如，它高度依赖守护进程，导致资源占用明显高于预期，启动速度也难以令人满意。
更关键的是，Docker 默认以 root 权限运行容器，极易放大潜在攻击面，在安全合规日益严格的今天，这一点令人担忧。Kubernetes 的官方运行时也已从 Docker 切换为 containerd 与 runc，表明行业主流已在悄然转向。
这并不意味着 Docker 已过时，它依旧在许多团队中扮演重要角色。但如果你期待更高的性能、更低的资源消耗和更强的安全隔离，那么，是时候拓宽视野了。
三、本地开发的难题与新解法
特别是在本地开发场景中，Docker 的“不够轻”问题尤为突出。为了启动一个简单的 PHP 或 Node 项目，很多人不得不拉起庞大的容器，等待镜像下载、构建，甚至调试端口映射，最终电脑风扇轰鸣，开发体验直线下降。
一些开发者试图回归传统，通过 Homebrew 或 apt 手动配置开发环境，但这又陷入了“版本冲突”“依赖错位”等老问题。
这时，ServBay 的出现带来了新的可能。作为专为本地开发设计的轻量级工具，ServBay 不依赖 Docker，也无需繁琐配置。用户只需一键启动，即可在本地运行 PHP、Python、Golang、Java 等多种语言环境，并能自由切换版本与服务组合。它不仅启动迅速，资源占用也极低，非常适合 WordPress、Laravel、ThinkPHP 等项目的本地调试与开发。
更重要的是，ServBay 不再强制开发者理解复杂的镜像构建与容器编排逻辑，而是将本地开发流程变得像打开编辑器一样自然。对于 Web 后端和全栈开发者来说，它提供了一种“摆脱 Docker”的全新路径。
四、当 Docker 不再是运行时的唯一选择
容器运行时的格局也在悄然生变。containerd 和 runc 成为了 Kubernetes 官方推荐的运行时，它们更轻、更专注，仅提供核心的容器管理功能，剥离了不必要的附加组件。与此同时，CRI-O 正在被越来越多团队采纳，它是专为 Kubernetes 打造的运行时，直接对接 CRI 接口，减少了依赖层级。
另一款备受好评的是 Podman，它的最大亮点在于支持 rootless 模式，使容器运行更加安全。同时，它的命令行几乎与 Docker 完全兼容，开发者几乎不需要重新学习。
对于安全隔离要求极高的场景，还可以选择 gVisor 或 Kata Containers。前者通过用户态内核方式拦截系统调用，构建沙箱化环境；后者则将轻量虚拟机与容器结合，兼顾性能与隔离性。这些方案正在逐步替代传统 Docker，成为新一代容器架构的基石。
五、容器编排：Kubernetes 之后的路在何方？
虽然 Kubernetes 仍然是企业级容器编排的标准选项，但它的复杂性和陡峭的学习曲线也让不少中小团队望而却步。一个简单的应用部署可能涉及上百行 YAML 文件，过度的抽象与组件拆分反而拉高了运维门槛。
这也促使“微型 Kubernetes”方案逐渐兴起。K3s 是其中的代表，它对 Kubernetes 进行了极大简化，专为边缘计算和资源受限场景优化。此外，像 KubeEdge 等项目，也在积极拓展容器编排在边缘设备上的适配能力。
与此同时，AI 驱动的编排平台正在探索新路径。CAST AI、Loft Labs 等团队推出的智能调度系统，可以自动分析工作负载并进行优化部署，最大化资源利用率。更进一步，Serverless 与容器的融合也逐渐成熟，比如 AWS Fargate、Google Cloud Run 等服务，让开发者无需再关心节点管理，容器真正变成了“即用即走”的计算单元。
六、未来趋势：容器走向“定制化生长”
未来的容器化，我们将看到更细化的技术选型：开发环境选择轻量灵活的本地容器，测试环境强调快速重建与自动化部署，生产环境则关注安全隔离与高可用性。
安全性也会成为核心关键词。rootless 容器、沙箱机制和系统调用过滤将成为主流实践，容器从“不可信”向“可信执行环境”演进。与此同时，人工智能将在容器调度中发挥更大作用，不仅提升弹性伸缩的效率，还可能引领“自愈系统”发展，让集群具备自我诊断与恢复能力。
容器标准如 OCI 的持续完善，将让不同运行时之间更加兼容，为整个生态的整合提供可能。而在部署端，我们也将看到容器由本地向云端、再向边缘设备的自然扩展，真正成为“无处不在的基础设施”。
七、结语：容器化的新纪元已经到来
Docker 的故事并没有结束，它依然是很多开发者最熟悉的工具，也在部分场景中继续发挥作用。但可以确定的是，它不再是唯一选择。2025 年的容器世界，早已迈入了多元化、场景化、智能化的阶段。从轻量级的 ServBay 到更安全的 Podman，从微型编排到 Serverless 混合模式，我们手中可选的工具越来越丰富，技术栈的自由度也空前提升。
下一个十年，容器不只是为了“装下服务”，它将成为构建现代基础设施的关键砖块。愿你也能在这场演进中，找到属于自己的工具组合，打造更轻、更快、更自由的开发与部署体验。
来源：juejin.cn/post/7521927128524210212
放弃 JSON.parse(JSON.stringify()) 吧！试试现代深拷贝！
作者：程序员成长指北
原文：mp.weixin.qq.com/s/WuZlo_92q…
最近小组里的小伙伴，暂且叫小A吧，问了一个bug：
提示数据循环引用，相信不少小伙伴都遇到过类似问题，于是我问他：
我：你知道问题报错的点在哪儿吗
小A： 知道，就是下面这个代码，但不知道怎么解决。
onst a = {};
const b = { parent: a };
a.child = b; // 形成循环引用
try {
const clone = JSON.parse(JSON.stringify(a));
} catch (error) {
console.error('Error:', error.message); // 会报错：Converting circular structure to JSON
}
上面是我将小A的业务代码提炼为简单示例，方便阅读。
- 这里
a.child指向b，而b.parent又指回a，形成了循环引用。 - 用
JSON.stringify时会抛出 Converting circular structure to JSON 的错误。
我顺手查了一下小A项目里 JSON.parse(JSON.stringify()) 的使用情况：
一看有50多处都使用了， 使用频率相当高了。
我继续提问：
我：你有找解决方案吗?
小A: 我看网上说可以自己实现一个递归来解决，但是我不太会实现
于是我帮他实现了一版简单的递归深拷贝：
function deepClone(obj, hash = new Map()) {
if (typeof obj !== 'object' || obj === null) return obj;
if (hash.has(obj)) return hash.get(obj);
const clone = Array.isArray(obj) ? [] : {};
hash.set(obj, clone);
for (const key in obj) {
if (obj.hasOwnProperty(key)) {
clone[key] = deepClone(obj[key], hash);
}
}
return clone;
}
// 测试
const a = {};
const b = { parent: a };
a.child = b;
const clone = deepClone(a);
console.log(clone.child.parent === clone); // true
此时,为了给他拓展一下，我顺势抛出新问题：
我： 你知道原生Web API 现在已经提供了一个深拷贝 API吗？
小A:？？？
于是我详细介绍了一下：
主角 structuredClone登场
structuredClone() 是浏览器原生提供的 深拷贝 API，可以完整复制几乎所有常见类型的数据，包括复杂的嵌套对象、数组、Map、Set、Date、正则表达式、甚至是循环引用。
它遵循的标准是：HTML Living Standard - Structured Clone Algorithm（结构化克隆算法）。
语法：
const clone = structuredClone(value);
一行代码，优雅地解决刚才的问题：
const a = {};
const b = { parent: a };
a.child = b; // 形成循环引用
const clone = structuredClone(a);
console.log(clone !== a); // true
console.log(clone.child !== b); // true
console.log(clone.child.parent === clone); // true，循环引用关系被保留
为什么增加 structuredClone？
在 structuredClone 出现之前，常用的深拷贝方法有：
| 方法 | 是否支持函数/循环引用 | 是否支持特殊对象 |
|---|---|---|
JSON.parse(JSON.stringify(obj)) | ❌ 不支持函数、循环引用 | ❌ 丢失 Date、RegExp、Map、Set |
第三方库 lodash.cloneDeep | ✅ 支持 | ✅ 支持，但体积大，速度较慢 |
| 手写递归 | ✅ 可支持 | ❌ 复杂、易出错 |
structuredClone 是 原生、极速、支持更多数据类型且无需额外依赖 的现代解决方案。
支持的数据类型
| 类型 | 支持 |
|---|---|
| Object | ✔️ |
| Array | ✔️ |
| Map / Set | ✔️ |
| Date | ✔️ |
| RegExp | ✔️ |
| ArrayBuffer / TypedArray | ✔️ |
| Blob / File / FileList | ✔️ |
| ImageData / DOMException / MessagePort | ✔️ |
| BigInt | ✔️ |
| Symbol（保持引用） | ✔️ |
| 循环引用 | ✔️ |
❌ 不支持：
- 函数（Function）
- DOM 节点
- WeakMap、WeakSet
常见使用示例
1. 克隆普通对象
const obj = { a: 1, b: { c: 2 } };
const clone = structuredClone(obj);
console.log(clone); // { a: 1, b: { c: 2 } }
console.log(clone !== obj); // true
2. 支持循环引用
const obj = { name: 'Tom' };
obj.self = obj;
const clone = structuredClone(obj);
console.log(clone.self === clone); // true
3. 克隆 Map、Set、Date、RegExp
const complex = {
map: new Map([["key", "value"]]),
set: new Set([1, 2, 3]),
date: new Date(),
regex: /abc/gi
};
const clone = structuredClone(complex);
console.log(clone);
兼容性
提到新的API，肯定得考虑兼容性问题：
- Chrome 98+
- Firefox 94+
- Safari 15+
- Node.js 17+ (
global.structuredClone)
如果需要兼容旧浏览器：
- 可以降级使用
lodash.cloneDeep - 或使用 MessageChannel Hack
很多小伙伴一看到兼容性问题，可能心里就有些犹豫：
"新API虽然好，但旧浏览器怎么办？"
但技术的发展离不开新技术的应用和推广，只有更多人开始尝试并使用，才能让新API真正普及开来，最终成为主流。
建议：
如果你的项目运行在现代浏览器或 Node.js 环境，structuredClone 是目前最推荐的深拷贝方案。 Node.js 17+：可以直接使用 global.structuredClone。
来源：juejin.cn/post/7524232022124085257
localhost 和 127.0.0.1 到底有啥区别？
在开发中，我们经常会接触到 localhost 和 127.0.0.1。很多人可能觉得它们是一样的，甚至可以互换使用。实际上，它们确实有很多相似之处，但细究起来，也存在一些重要的区别。
本篇文章就带大家一起来深入了解 localhost 和 127.0.0.1，并帮助你搞清楚它们各自的特点和适用场景。
一、什么是 localhost？
localhost 是一个域名，它被广泛用于表示当前这台主机（也就是你自己的电脑）。当你在浏览器地址栏输入 localhost 时，操作系统会查找 hosts 文件（在 Windows 中通常位于 C:\Windows\System32\drivers\etc\hosts，在 MacOS 或者 Linux 系统中，一般位于 /etc/hosts），查找 localhost 对应的 IP 地址。如果没有找到，它将默认解析为 127.0.0.1。
特点：
- 是一个域名，默认指向当前设备。
- 不需要联网也能工作。
- 用于测试本地服务，例如开发中的 Web 应用或 API。
小知识 🌟：域名和 IP 地址的关系就像联系人名字和电话号码。我们用名字联系某个人，实际上是依赖后台的通讯录解析到实际号码来拨号。
二、什么是 127.0.0.1？
127.0.0.1 是一个特殊的 IP 地址，它被称为 回环地址（loopback address）。这个地址专门用于通信时指向本机，相当于告诉电脑“别出门，就在家里转一圈”。你可以试一试在浏览器中访问 127.0.0.2 看看会访问到什么？你会发现，它同样会指向本地服务！环回地址的范围是 127.0.0.0/8，即所有以 127 开头的地址都属于环回网络，但最常用的是 127.0.0.1。
特点：
- 127.0.0.1 不需要 DNS 解析，因为它是一个硬编码的地址，直接指向本地计算机。
- 是 IPv4 地址范围中的一个保留地址。
- 只用于本机网络通信，不能通过这个地址访问外部设备或网络。
- 是开发测试中最常用的 IP 地址之一。
小知识 🌟：所有从
127.0.0.0到127.255.255.255的 IP 地址都属于回环地址，但通常只用127.0.0.1。
三、两者的相似点
- 都指向本机
- 不管是输入
localhost还是127.0.0.1，最终都会将请求发送到你的电脑，而不是其他地方。
- 不管是输入
- 常用于本地测试
- 在开发中，我们需要在本机运行服务并测试，
localhost和127.0.0.1都是标准的本地访问方式。
- 在开发中，我们需要在本机运行服务并测试，
- 无需网络支持
- 即使你的电脑没有连接网络，这两个也可以正常使用，因为它们完全依赖于本机的网络栈。
四、两者的不同点
| 区别 | localhost | 127.0.0.1 |
|---|---|---|
| 类型 | 域名 | IP 地址 |
| 解析过程 | 需要通过 DNS 或 hosts 文件解析为 IP 地址 | 不需要解析，直接使用 |
| 协议版本支持 | 同时支持 IPv4 和 IPv6 | 仅支持 IPv4 |
| 访问速度 | 解析时可能稍慢（视 DNS 配置而定） | 通常更快，因为不需要额外的解析步骤 |
五、为什么 localhost 和 127.0.0.1 有时表现不同？
在大多数情况下，localhost 和 127.0.0.1 是等效的，但在一些特殊环境下，它们可能会表现出差异：
1. IPv4 和 IPv6 的影响
localhost 默认可以解析为 IPv4（127.0.0.1）或 IPv6（::1）地址，具体取决于系统配置。如果你的程序只支持 IPv4，而 localhost 被解析为 IPv6 地址，可能会导致连接失败。
示例：
# 测试 localhost 是否解析为 IPv6
ping localhost
可能的结果：
- 如果返回
::1，说明解析为 IPv6。 - 如果返回
127.0.0.1，说明解析为 IPv4。
2. hosts 文件配置
在某些情况下，你的 localhost 并不一定指向 127.0.0.1。这是因为域名解析优先会查找系统的 hosts 文件：
- Windows：
C:\Windows\System32\drivers\etc\hosts - Linux/macOS：
/etc/hosts
示例：自定义 localhost
# 修改 hosts 文件
127.0.0.1 my-local
之后访问 http://my-local 会指向 127.0.0.1，但如果 localhost 被误配置成其他地址，可能会导致问题。
3. 防火墙或网络配置的限制
某些网络工具或防火墙规则会区别对待域名和 IP 地址。如果只允许 127.0.0.1 通信，而不允许 localhost，可能会引发问题。
六、在开发中如何选择？
- 优先使用
localhost
因为它是更高层次的表示方式，更通用。如果将来需要切换到不同的 IP 地址（例如 IPv6），不需要修改代码。 - 需要精准控制时用
127.0.0.1
如果你明确知道程序只需要使用 IPv4 环境，或者想避免域名解析可能带来的问题，直接用 IP 地址更稳妥。
示例：用 Python 测试
# 使用 localhost
import socket
print(socket.gethostbyname('localhost')) # 输出可能是 127.0.0.1 或 ::1
# 使用 127.0.0.1
print(socket.gethostbyname('127.0.0.1')) # 输出始终是 127.0.0.1
七、总结
虽然 localhost 和 127.0.0.1 大部分情况下可以互换使用，但它们的本质不同：
localhost是域名，更抽象。127.0.0.1是 IP 地址，更具体。
在开发中，我们应根据场景合理选择，尤其是在涉及到跨平台兼容性或网络配置时，理解它们的差异性会让你事半功倍。
最后，记得动手实践，多跑几个测试。毕竟，编程是用代码说话的艺术！😄
如果你觉得这篇文章对你有帮助，记得点个赞或分享给更多人！有其他技术问题想了解？欢迎评论区留言哦~ 😊
来源：juejin.cn/post/7511583779578200115
都说了布尔类型的变量不要加 is 前缀，非要加，这不是坑人了嘛
开心一刻
今天心情不好，给哥们发语音
我：哥们，晚上出来喝酒聊天吧
哥们：咋啦，心情不好？
我：嗯，刚刚在公交车上看见前女友了
哥们：然后呢？
我：给她让座时，发现她怀孕了...
哥们：所以难受了？
我：不是她怀孕让我难受，是她怀孕还坐公交车让我难受
哥们：不是，她跟着你就不用坐公交车了？不还是也要坐，有区别吗？
我默默的挂断了语音，心情更难受了
Java开发手册
作为一个 javaer，我们肯定看过 Alibaba 的 Java开发手册，作为国内Java开发领域的标杆性编码规范，我们或多或少借鉴了其中的一些规范，其中有一点
我印象特别深，也一直在奉行，自己还从未试过用 is 作为布尔类型变量的前缀，不知道会有什么坑；正好前段时间同事这么用了，很不幸，他挖坑，我踩坑，阿西吧！
is前缀的布尔变量有坑
为了复现问题，我先简单搞个 demo；调用很简单，服务 workflow 通过 openfeign 调用 offline-sync，代码结构如下
qsl-data-govern-common：整个项目的公共模块
qsl-offline-sync：离线同步
- qsl-offline-sync-api：向外提供
openfeign接口
- qsl-offline-sync-common：离线同步公共模块
- qsl-offline-sync-server：离线同步服务
qsl-workflow：工作流
- qsl-workflow-api：向外提供
openfeign接口，暂时空实现
- qsl-workflow-common：工作流公共模块
- qsl-workflow-server：工作流服务
完整代码：qsl-data-govern
qsl-offline-sync-server 提供删除接口
/**
* @author 青石路
*/
@RestController
@RequestMapping("/task")
public class SyncTaskController {
private static final Logger LOG = LoggerFactory.getLogger(SyncTaskController.class);
@PostMapping("/delete")
public ResultEntity<String> delete(@RequestBody SyncTaskDTO syncTask) {
// TODO 删除处理
LOG.info("删除任务[taskId={}]", syncTask.getTaskId());
return ResultEntity.success("删除成功");
}
}
qsl-offline-sync-api 对外提供 openfeign 接口
/**
* @author 青石路
*/
@FeignClient(name = "data-govern-offline-sync", contextId = "dataGovernOfflineSync", url = "${offline.sync.server.url}")
public interface OfflineSyncApi {
@PostMapping(value = "/task/delete")
ResultEntity<String> deleteTask(@RequestBody SyncTaskDTO syncTaskDTO);
}
qsl-workflow-server 调用 openfeign 接口
/**
* @author 青石路
*/
@RestController
@RequestMapping("/definition")
public class WorkflowController {
private static final Logger LOG = LoggerFactory.getLogger(WorkflowController.class);
@Resource
private OfflineSyncApi offlineSyncApi;
@PostMapping("/delete")
public ResultEntity<String> delete(@RequestBody WorkflowDTO workflow) {
LOG.info("删除工作流[workflowId={}]", workflow.getWorkflowId());
// 1.查询工作流节点，查到离线同步节点（taskId = 1）
// 2.删除工作流节点，删除离线同步节点
ResultEntity<String> syncDeleteResult = offlineSyncApi.deleteTask(new SyncTaskDTO(1L));
if (syncDeleteResult.getCode() != 200) {
LOG.error("删除离线同步任务[taskId={}]失败：{}", 1, syncDeleteResult.getMessage());
ResultEntity.fail(syncDeleteResult.getMessage());
}
return ResultEntity.success("删除成功");
}
}
逻辑是不是很简单？我们启动两个服务，然后发起 http 请求
POST http://localhost:8081/data-govern/workflow/definition/delete
Content-Type: application/json
{
"workflowId": 99
}
此时 qsl-offline-sync-server 日志输出如下
2025-06-30 14:53:06.165|INFO|http-nio-8080-exec-4|25|c.q.s.s.controller.SyncTaskController :删除任务[taskId=1]
至此，一切都很正常，第一版也是这么对接的；后面 offline-sync 进行调整，删除接口增加了一个参数：isClearData
public class SyncTaskDTO {
public SyncTaskDTO(){}
public SyncTaskDTO(Long taskId, Boolean isClearData) {
this.taskId = taskId;
this.isClearData = isClearData;
}
private Long taskId;
private Boolean isClearData = false;
public Long getTaskId() {
return taskId;
}
public void setTaskId(Long taskId) {
this.taskId = taskId;
}
public Boolean getClearData() {
return isClearData;
}
public void setClearData(Boolean clearData) {
isClearData = clearData;
}
}
然后实现对应的逻辑
/**
* @author 青石路
*/
@RestController
@RequestMapping("/task")
public class SyncTaskController {
private static final Logger LOG = LoggerFactory.getLogger(SyncTaskController.class);
@PostMapping("/delete")
public ResultEntity<String> delete(@RequestBody SyncTaskDTO syncTask) {
// TODO 删除处理
LOG.info("删除任务[taskId={}]", syncTask.getTaskId());
if (syncTask.getClearData()) {
LOG.info("清空任务[taskId={}]历史数据", syncTask.getTaskId());
// TODO 清空历史数据
}
return ResultEntity.success("删除成功");
}
}
调整完之后，同事通知我，让我做对 qsl-workflow 做对应的调整。调整很简单，qsl-workflow 删除时直接传 true 即可
/**
* @author 青石路
*/
@RestController
@RequestMapping("/definition")
public class WorkflowController {
private static final Logger LOG = LoggerFactory.getLogger(WorkflowController.class);
@Resource
private OfflineSyncApi offlineSyncApi;
@PostMapping("/delete")
public ResultEntity<String> delete(@RequestBody WorkflowDTO workflow) {
LOG.info("删除工作流[workflowId={}]", workflow.getWorkflowId());
// 1.查询工作流节点，查到离线同步节点（taskId = 1）
// 2.删除工作流节点，删除离线同步节点
// 删除离线同步任务，isClearData直接传true
ResultEntity<String> syncDeleteResult = offlineSyncApi.deleteTask(new SyncTaskDTO(1L, true));
if (syncDeleteResult.getCode() != 200) {
LOG.error("删除离线同步任务[taskId={}]失败：{}", 1, syncDeleteResult.getMessage());
ResultEntity.fail(syncDeleteResult.getMessage());
}
return ResultEntity.success("删除成功");
}
}
调整完成之后，发起 http 请求，发现历史数据没有被清除，看日志发现
LOG.info("清空任务[taskId={}]历史数据", syncTask.getTaskId());
没有打印，参数明明传的是 true 吖！！！
offlineSyncApi.deleteTask(new SyncTaskDTO(1L, true));
这是哪里出了问题？
问题排查
因为 qsl-offline-sync-api 是直接引入的，并非我实现的，所以我第一时间找到了其实现者，反馈了问题后让其自测下；一开始他还很自信，说这么简单怎么会有问题
当他启动 qsl-offline-sync-server 后，发起 http 请求
POST http://localhost:8080/data-govern/sync/task/delete
Content-Type: application/json
{
"taskId": 123,
"isClearData": true
}
发现 isClearData 的值是 false
此刻，疑问从我的额头转移到了他的额头上，他懵逼了，我轻松了。为了功能能够正常交付，我还是决定看下这个问题，没有了心理压力，也许更容易发现问题所在。第一眼看到 isClearData，我就隐约觉得有问题，所以我决定仔细看下 SyncTaskDTO 这个类，发现 isClearData 的 setter 和 getter 方法有点不一样
private Boolean isClearData = false;
public Boolean getClearData() {
return isClearData;
}
public void setClearData(Boolean clearData) {
isClearData = clearData;
}
方法名是不是少了 Is？带着这个疑问我找到了同事，问他 setter 、getter 为什么要这么命名？他说是 idea 工具自动生成的（也就是我们平时用到的idea自动生成setter、getter方法的功能）
我让他把 Is 补上试试
private Boolean isClearData = false;
public Boolean getIsClearData() {
return isClearData;
}
public void setIsClearData(Boolean isClearData) {
this.isClearData = isClearData;
}
发现传值正常了，他回过头看着我，我看着他，两人同时提问
他：为什么加了
Is就可以了？
我：布尔类型的变量，你为什么要加
is前缀？
问题延申
作为一个严谨的开发，不只是要知其然，更要知其所以然；关于
为什么加了
Is就可以了
这个问题，我们肯定是要会上一会的；会这个问题之前，我们先来捋一下参数的流转，因为是基于 Spring MVC 实现的 Web 应用，所以我们可以这么问 deepseek
Spring MVC 是如何将前端参数转换成POJO的
能够查到如下重点信息
RequestResponseBodyMethodProcessor 的 resolveArgument
/**
* Throws MethodArgumentNotValidException if validation fails.
* @throws HttpMessageNotReadableException if {@link RequestBody#required()}
* is {@code true} and there is no body content or if there is no suitable
* converter to read the content with.
*/
@Override
public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
parameter = parameter.nestedIfOptional();
Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
String name = Conventions.getVariableNameForParameter(parameter);
if (binderFactory != null) {
WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
if (arg != null) {
validateIfApplicable(binder, parameter);
if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {
throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
}
}
if (mavContainer != null) {
mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
}
}
return adaptArgumentIfNecessary(arg, parameter);
}
正是解析参数的地方，我们打个断点，再发起一次 http 请求
很明显，readWithMessageConverters 是处理并转换参数的地方，继续跟进去会来到 MappingJackson2HttpMessageConverter 的 readJavaType 方法
此刻我们可以得到，是通过 jackson 完成数据绑定与数据转换的。继续跟进，会看到 isClearData 的赋值过程
通过前端传过来的参数 isClearData 找对应的 setter方法是 setIsClearData，而非 setClearData，所以问题
为什么加了
Is就可以了
是不是就清楚了？
问题解决
- 按上述方式调整
isClearData的setter、getter方法
带上
is
public Boolean getIsClearData() {
return isClearData;
}
public void setIsClearData(Boolean isClearData) {
this.isClearData = isClearData;
}
- 布尔类型的变量，不用
is前缀
可以用
if前缀
private Boolean ifClearData = false;
public Boolean getIfClearData() {
return ifClearData;
}
public void setIfClearData(Boolean ifClearData) {
this.ifClearData = ifClearData;
}
- 可以结合
@JsonProperty来处理
@JsonProperty("isClearData")
private Boolean isClearData = false;
总结
Spring MVC对参数的绑定与转换，内容不同，采用的处理器也不同
- form表单数据(application/x-www-form-urlencoded)
处理器：
ServletModelAttributeMethodProcessor - JSON 数据 (application/json)
处理器：
RequestResponseBodyMethodProcessor
转换器：MappingJackson2HttpMessageConverter - 多部分文件 (multipart/form-data)
处理器：
MultipartResolver
- form表单数据(application/x-www-form-urlencoded)
POJO的布尔类型变量，不要加is前缀
命名不符合规范，集成第三方框架的时候就很容易出不好排查的问题
成不了规范的制定者，那就老老实实遵循规范！
来源：juejin.cn/post/7521642915278422070
这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
通过这次折腾，我成功地让闲置的 Ubuntu 服务器重新焕发生机，变成了一个功能强大的家庭影院。希望我的经验能够对大家有所帮助，也欢迎大家一起交流更多关于服务器利用和家庭影院搭建的经验。
