找对象真的太难了，我不由地发出这个感慨

但其实说着也奇怪，明明我每天两点一线，上班了去工位、下班了回宿舍，根本没有其他社交，但我为什么会发出这样的感慨呢？

• 是因为总是在无聊时感到了孤独才希望有个伴，还是看见大家都有伴了才觉得自己孤独？


• 是因为看到了别人功成名就家庭和谐的嫉妒，还是吊儿郎当无所事事地调侃？


• 是因为信息茧房导致我对婚姻产生了偏见而刻意疏远，还是无能狂怒般自卑不敢去尝试？


• ……

如果是针对我个人的话，那应该是自卑了吧。这辈子30多年没什么情感经历，就只有一次相亲后“交往”的经验。那次相亲后异地聊了9个月，中间节假日只有我回去见了3次面，没有矛盾，每天都在线上花个两三个小时也都聊得很开心，但我却总觉得彼此都像个不熟的人，以至于最后“分手”时内心也毫无波澜。

“或许我根本不需要为了找个伴才选择想找对象吧。”我总是这样安慰自己，其实安慰的次数不多，因为我没有经常想。

我每天两点一线的生活很规律，很轻松，最重要的是，我已经非常习惯了。所以从某种程度来讲，“客观上”，我并没有真的想找对象、也没有主动去尝试结交新朋友，“主观上”，现在的社会风向和经济形势，不太利于我尝试告别单身，即便 A 股沪指最近持续性突破十年新高。

光是想，不去做，那可不就是“太难了”。

其实，有那么一瞬间我也想结婚

可怜的是，这并不是基于我个人的想法，而是外界的干扰。我记得我31岁生日那天，凌晨6点过还在睡梦中，外公外婆就打来电话，祝我生日快乐。我很诧异，因为我没想到农忙时节呢，他们还没忙忘了，也因为居然这么早，鸡鸭才刚叫。然后一如既往地说：不要太节约了，吃点好的，照顾好自己……然后，快点找对象，天天瞌睡都睡不好，揪心得很哦。结了婚他们就放心了，不然他们死了都不安心哦。

或许80多岁的老人家觉得，任何事情，只要你想要，那就能发生。我想要天上掉金子，天上就会掉金子；我想要地里喷石油，地里就会喷石油；我想要找对象，自然就有对象……

我倒是习以为常了，只不过那一整天，就没有第二个人祝我生日快乐了。不管是朋友同事，还是父母亲戚，即便是早我一天过生日、而我在生日前一天给她发去生日祝福的堂姐，都没有。

其实我也是习以为常了，可能因为我的生日也是我爷爷的忌日，我总是刻意淡忘它，大部分时候过生日我自己都会忘记，10岁之后就没有任何一次庆祝生日的行为——10岁那年父母要都外出打工，自此再次成为留守儿童。

但今年有那么一瞬间，突然觉得难得只有两个80多岁的老人还记得我生日，一直让他们失望有点于心不忍，更何况，正常来讲，我还能“忤逆”他们多少年呢？

可惜的是，就和那些贩卖焦虑的短视频、营销号一样，总是提出问题、夸大问题、制造矛盾、激化矛盾，但从来不会提供解决方法一样：想结婚了，然后呢？

独身一人在无聊的时候确实是无聊的

最近不知道是上班天天盯着电脑看久了，还是下班游戏玩多了，眼睛特别酸痛，于是我难得的又在下班之后出去逛了逛。

正常的话吃了饭我就玩游戏了，先玩几把NBA 2K，再玩几把英雄联盟手游，再玩几把王者荣耀。

其实曾几何时，我从生理上都厌恶王者荣耀的，因为它把很多中国历史人物文化名人，搞成游戏中乱七八糟的角色，让我无法接受。以至于这么多年来，从同学同事、到堂表兄弟等，都没有机会跟我一起玩。

我也没想到我居然突然之间就接受了，即便这曾经让我生理上讨厌的东西。我记得很清楚，2025年7月2日，我新历生日那天，我下载了王者荣耀，建立了账号，开始游玩，持续十几天有空就一直在玩，一百来把、十几级的账号打到最低等级的王者段位，觉得差不多入门了，想着和老同学、老朋友、老同事们一起玩时，才发现他们都不上线了。或许，随着年龄的增长，这种“年轻时的生理厌恶”都敌不过“无聊时的孤单寂寞”。

所以每次当我一个人出去小道散步闲逛消磨时间时，总会特别在意那些跑步锻炼身体的人、散步话家常的两公婆、坐在摊位小车后面玩手机的摆摊老板……感觉他们都有目的地在做什么，而只有我在漫无目的地走着。

其实这条路我之前走过，至少在我今年生日之前，只不过那个时候，这马路边的行人道，没有这么多杂草、灌木。就像人生路，总是在回忆的时候，才觉得曾经如此宽阔，才懊悔当时未曾踏入。可是，时光一直向前流逝，回忆永远迭代更新。

可能现在生活没有达到预期的我们总是有这样的想法，要是能回到过去就好了。实际上只是想带着现在的记忆回到过去，去弥补一些错过或者错误。似乎真像有多元宇宙，回到过去之后会有新的时间线，补足那些遗憾，每一次的回溯，终究会得到一条完美符合心意的时间线。实际上我觉得，即便我们能回到过去，那也是会失去所有记忆，然后完完整整重复之前做过的事情，又一次的错过或者错误，不会有多条时间线，即便你回去再多次，都只会重复同样的事情，都只是同一条时间线。但只有这一条时间线，其实也就够了。

正因为消极，所以才乐观

其实我一直是希望传播积极乐观心态的，从我以往的文章总能看到有这样的痕迹。但就像那些奢侈品广告一样：你买得起不重要，你买不起才重要。

就像我当年创业板3600多点最高峰买入了很多和创业板强关联基金一样，那时总觉得中国经济一定是蒸蒸日上，最后一路跌倒了1500点，一点点割肉，最后全盘清掉，赔了一些钱，然后不敢再入场。所以我也没赶上或者说是错过了今年大半年的牛市，有点难受。与之相对的，为了求稳买入了大量的债券，却债市正熊，又套在手里，更难受了。

可能这都不是什么大事，毕竟只是对我造成了一些经济损失，并不会影响到我的一如既往平凡普通的物质生活；但是焦虑、担忧、烦闷的心态，却非常影响我的精神状态，严重损坏我本就低迷的精神生活。

我一直有个想法，希望尽量在35岁前能多攒一些钱，这样如果35岁之后某天丢了工作，我就徒步去环游中国。并不是他们那种雄心壮志地环游，什么“朝圣“”啊、“远离浮躁净化心灵”啊。就跟平时一样，大街小巷，散步流浪，随便走走看看，不过变成了走到哪里黑，就到哪里歇。等到钱花光了，人老了走不动，客死他乡，也算得偿所愿了。

如果真的能到这个时候，身后没有拖拽、肩上没有负担，该是多么舒服的境况。

发现了吗，其实我就是这么矛盾，一方面安慰自己钱财乃身外物，不必强求；另一方面又觉得钱财乃必需品，多多益善。原因非常简单，因为我缺这东西，所以看得很重；又因为没本事挣到更多，所以才安慰自己它不重要。

这就是别人说的，看清问题根源比无法解决问题更让人窒息，也就是“无知是福”或者”无知者无畏”的感悟了。

每个人都应该有自己的活法，即便大同小异

正如写代码的人，总是会重复造轮子，偶尔还会乐此不疲。世上的人这么多，大部分的人的都是千篇一律的，事实上，大家都在做的事情，说不定才是对的。大家都重复着读书、工作、结婚、生子、工作、退休、等死的生活，正是因为在和平年代这就是一个非常典型且应该让人轻松愉悦、容易接受的平凡人的人生。

同样功能、完全适配你项目的工具包，一个周下载几百万、上次更新1个月前，一个周下载几十、上次更新5年前，只考虑下载使用的话，你会怎么选呢？

就像正因为他是魔丸才敢高喊“我命由我不由天”，就像有人说对钱不感兴趣；也就像也有人觉得“奋斗用多大劲啊？”就像我以为“忠诚的不绝对就是绝对的不忠诚”只是一个战锤40K的梗而已……这个世界本来就因为科技发展而不断更新，止不住的时代洪流，纷纷扰扰的世界，何必太关注别人关心的事情，兜兜转转可能发现，你特别在意的东西别人根本没放在心上，你漫不经心地言语却刺穿了别人的心脏。所有的一切，在心脏停止跳动之前，其实都无关紧要；而在心脏停止跳动之后，更是毫无意义。

所以我平时有空的时候，也会更新一下我 Github 仓库中几个开源的小项目，虽然没什么技术含量，还借助了很多AI辅助编码，但我在写完测试完成之后的那一刻感觉很舒服，就算之后很久都没再更新、测试，还发现了bug，但那完成时的一瞬间很舒服，就成了我持续不断更新的主观能动性之一。

人总有一死，我一直强调不要太在意他人的眼光，为自己而生活。但如果你根本不知道自己想要过什么样的人生，那么从众并不是什么丢人的行为。 人生短暂，不值得斤斤计较，浪费也是它应该存在的过程片段。

坐在厂门口的女子

我今天出去散步的时候，经过了隔壁厂，恰巧看到一位女士蹲在门口马路牙子上，左手拿着装炸土豆片套着塑料袋的小盒子，右手拿着手机看小说。我在外面溜达了个把小时，回去的时候发现她还蹲着那马路牙子上，可能是同一个位置，只不过只有右手拿着手机继续看着小说。

但我猜测她“可能”并没有一直蹲着那里看小说，因为那装炸土豆片的小纸盒没有在她左手上继续拿着，也没有放在她的身旁……

为什么只是“猜测和可能”呢？谁知道呢，或许她站起来走几步丢到垃圾桶后又蹲回去了，或许只是她吃完了空纸盒子放在旁边被风吹走了；或许她没吃完揉吧揉吧纸盒子随手丢到马路对面去了，又或许甚至可能她变身奥特曼打走了怪兽又变回正常人继续在厂门口看小说了……

如果不是因为间隔这么久，看见她还呆在同一个位置，我可能根本就没在意。就像如果不是出来工作了10年依旧还在原地，我也不必过度“揣摩自己”。

可能因为总是太在意，所以才觉得一切都太难了…… 毕竟“得不到的永远在骚动……”

很难了，一个陌生人有两次遇到的机会。

多数情况下都只有一次机会。换成是我，如果我一开始也是蹲在厂门口的马路牙子上，估计没人会注意到。但我要是一开始就跪在厂门口不停在磕头，说不定就有人会注意到了……

结尾

哈哈，Gotcha！要不是我这几天玩游戏多了眼睛有点酸痛，需要休息一下，我才不会在这里长篇大论无病呻吟呢，都这么久没有更新了是吧，那我玩游戏看视频啥的时可是乐在其中、忘乎所以的，佝偻成一团都还在哈哈大笑呢。

所以，赶紧去做那些让你自己开心的事情吧，享受生活，这才是我们活着的原因之一，其他的事情，fxxk off。

什么是联合索引？

首先，要理解最左匹配原则，得先知道什么是联合索引。

• 单列索引：只针对一个表列创建的索引。例如，为 users 表的 name 字段创建一个索引。


• 联合索引：也叫复合索引，是针对多个表列创建的索引。例如，为 users 表的 (last_name, first_name) 两个字段创建一个联合索引。

这个索引的结构可以想象成类似于电话簿或字典。电话簿是先按姓氏排序，在姓氏相同的情况下，再按名字排序。你无法直接跳过姓氏，快速找到一个特定的名字。

什么是最左匹配原则？

最左匹配原则指的是：在使用联合索引进行查询时，MySQL/SQL数据库从索引的最左前列开始，并且不能跳过中间的列，一直向右匹配，直到遇到范围查询（>、<、BETWEEN、LIKE）就会停止匹配。

这个原则决定了你的 SQL 查询语句是否能够使用以及如何高效地使用这个联合索引。

核心要点：

举例说明

假设我们有一个 users 表，并创建了一个联合索引 idx_name_age，包含 (last_name, age) 两个字段。

索引 idx_name_age 在磁盘上大致是这样排序的（先按 last_name 排序，last_name 相同再按 age 排序）：

(Li, 30) (Wang, 20) (Wang, 22) (Zhang, 25) (Zhang, 28)

现在，我们来看不同的查询场景：

✅ 场景一：完全匹配最左列

SELECT * FROM users WHERE last_name = 'Wang';

• 分析：查询条件包含了索引的最左列 last_name。


• 索引使用情况：✅ 可以使用索引。数据库可以快速在索引树中找到所有 last_name = 'Wang' 的记录（(Wang, 20) 和 (Wang, 22)）。

✅ 场景二：匹配所有列

SELECT * FROM users WHERE last_name = 'Wang' AND age = 22;

• 分析：查询条件包含了索引的所有列，并且顺序与索引定义一致。


• 索引使用情况：✅ 可以高效使用索引。数据库先定位到 last_name = 'Wang'，然后在这些结果中快速找到 age = 22 的记录。

✅ 场景三：匹配最左连续列

SELECT * FROM users WHERE last_name = 'Zhang';

• 分析：虽然只用了 last_name，但它是索引的最左列。


• 索引使用情况：✅ 可以使用索引。和场景一类似。

❌ 场景四：跳过最左列

SELECT * FROM users WHERE age = 25;

• 分析：查询条件没有包含索引的最左列 last_name。


• 索引使用情况：❌ 无法使用索引。这就像让你在电话簿里直接找所有叫“伟”的人，你必须翻遍整个电话簿，也就是全表扫描。

⚠️ 场景五：包含最左列，但中间有断档

-- 假设我们有一个三个字段的索引 (col1, col2, col3) -- 查询条件为 WHERE col1 = 'a' AND col3 = 'c';

• 分析：虽然包含了最左列 col1，但跳过了 col2 直接查询 col3。


• 索引使用情况：✅ 部分使用索引。数据库只能使用 col1 来缩小范围，找到所有 col1 = 'a' 的记录。对于 col3 的过滤，它无法利用索引，需要在第一步的结果集中进行逐行筛选。

⚠️ 场景六：最左列是范围查询

SELECT * FROM users WHERE last_name > 'Li' AND age = 25;

• 分析：最左列 last_name 使用了范围查询 >。


• 索引使用情况：✅ 部分使用索引。数据库可以使用索引找到所有 last_name > 'Li' 的记录（即从 Wang 开始往后的所有记录）。但是，对于 age = 25 这个条件，由于 last_name 已经是范围匹配，age 列在索引中是无序的，因此数据库无法再利用索引对 age 进行快速筛选，只能在 last_name > 'Li' 的结果集中逐行检查 age。

总结与最佳实践

最左匹配原则的本质是由索引的数据结构（B+Tree） 决定的。索引按照定义的字段顺序构建，所以必须从最左边开始才能利用其有序性。

如何设计好的联合索引？

CoroutineScope 与 CoroutineContext 的概念

CoroutineContext (协程上下文)

CoroutineContext 是协程上下文，包含了协程运行时所需的所有信息。

比如：

• 管理协程流程（生命周期）的 Job。


• 管理线程的 ContinuationInterceptor，它的实现类 CoroutineDispatcher 决定了协程所运行的线程或线程池。

CoroutineScope (协程作用域)

CoroutineScope 是协程作用域，它通过 coroutineContext 属性持有了当前协程代码块的上下文信息。

比如，我们可以获取 Job 和 ContinuationInterceptor 对象：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext) // scope 并没有持有已有协程的上下文

    val outerJob = scope.launch {

        val innerJob = coroutineContext[Job]

        val interceptor = coroutineContext[ContinuationInterceptor]

        println("job: $innerJob, interceptor: $interceptor")

    }



    outerJob.join()

}

CoroutineScope 的另一个作用就是提供了 launch 和 async 协程构建器，我们可以通过它来启动一个协程。

这样，新创建的协程能够自动继承 CoroutineScope 的 coroutineContext。比如利用 Job，可以建立起父子关系，从而实现结构化并发。

GlobalScope

GlobalScope 是一个单例的 CoroutineScope 对象，所以我们在任何地方通过它来启动协程。

它的第二个特点是，它的 coroutineContext 属性是 EmptyCoroutineContext，也就是说它没有内置的 Job。

@DelicateCoroutinesApi

public object GlobalScope : CoroutineScope {

    /**

     * Returns [EmptyCoroutineContext].

     */

    override val coroutineContext: CoroutineContext

        get() = EmptyCoroutineContext

}

即使是我们手动创建的 CoroutineScope，其内部也是有 Job 的。

// 手动创建 CoroutineScope

CoroutineScope(EmptyCoroutineContext)



// CoroutineScope.kt

@Suppress("FunctionName")

public fun CoroutineScope(context: CoroutineContext): CoroutineScope =

    ContextScope(if (context[Job] != null) context else context + Job()) // 自动创建Job对象

所以我们在 GlobalScope.coroutineContext 中是获取不到 Job 的：

@OptIn(DelicateCoroutinesApi::class)

fun main() = runBlocking<Unit> {

    val job: Job? = GlobalScope.coroutineContext[Job]

    if (job == null) {

        println("job is null")

    }

    try {

        val jobNotNull: Job = GlobalScope.coroutineContext.job

    } catch (e: IllegalStateException) {

        println("job is null, exception is: $e")

    }

}

运行结果：

job is null

job is null, exception is: java.lang.IllegalStateException: Current context doesn't contain Job in it: EmptyCoroutineContext

那么，这有什么用吗？

其实，GlobalScope 所启动的协程没有父 Job。

这就意味着：

• 当前协程不和其他 Job 的生命周期绑定，比如不会随着某个界面的关闭而自动取消。


• 它是顶级协程，生命周期默认为整个应用的生命周期。


• 它发生异常，并不会影响到其他协程和 GlobalScope。反之，GlobalScope 本身也无法级联取消所有任务，因为它所启动的协程是完全独立的。

总结：GlobalScope 就是用来启动那些不与组件生命周期绑定，而是与整个应用生命周期保持一致的全局任务，比如一个日志上报任务。

关键在使用时，可能会有资源泄露的风险，需要正确管理好协程的生命周期。

Context 的三个实用工具

在挂起函数中获取 CoroutineContext

如果我们要在一个挂起函数中获取 CoroutineContext，我们不得不给将其作为 CoroutineScope 的扩展函数。

suspend fun CoroutineScope.printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

但我们知道挂起函数的外部一定有协程存在，所以是存在 CoroutineContext 的。为此，Kotlin 协程库提供了一个顶层的 coroutineContext 属性，这个属性的 get() 函数是一个挂起函数，它能在任何挂起函数中访问到当前正在执行的协程的 CoroutineContext。

import kotlin.coroutines.coroutineContext



suspend fun printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

另外，还有一个 currentCoroutineContext() 函数也能获取到 CoroutineContext，它内部实现也是 coroutineContext 属性。

为什么需要这个函数？

为了解决命名冲突，比如下面这段代码。

private fun mySuspendFun() {

    flow<String> {

        // 顶层属性

        coroutineContext 

    }



    GlobalScope.launch {

        flow<String> {

            // this 的成员属性优先级高于顶层属性

            // 所以是外层 launch 的 CoroutineScope 的成员属性 coroutineContext

            coroutineContext

        }

    }

}

在这种情况下，如果需要明确属性的源头，就需要使用 currentCoroutineContext() 函数，它会调用到那个顶层的属性。

CoroutineName 协程命名

CoroutineName 是一个协程上下文信息，我们可以使用它来给协程设置一个名称。

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext)

    val name = CoroutineName("coroutine-1")

    val job = scope.launch(name) {

        val coroutineName = coroutineContext[CoroutineName]

        println("current coroutine name: $coroutineName")

    }



    job.join()

}

运行结果：

current coroutine name: CoroutineName(coroutine-1)

它主要用于测试和调试，你可以使用它来区分哪些日志是哪个协程打印的。

自定义 CoroutineContext

如果我们要给协程附加一些功能，我们可以考虑自定义 CoroutineContext。

如果是简单的标记，可以优先考虑使用 CoroutineName。

自定义 CoroutineContext 需要实现 CoroutineContext.Element，并且提供 Key。为此，Kotlin 协程库提供了 AbstractCoroutineContextElement 来简化这个过程。我们只需这样，即可创建一个用于协程内部记录日志的 Context：

// 继承 AbstractCoroutineContextElement，并把 Key 传给父构造函数

class CoroutineLogger(val tag: String) : AbstractCoroutineContextElement(CoroutineLogger) {



    // 声明专属的 Key

    companion object Key : CoroutineContext.Key<CoroutineLogger>



    // 添加专属功能

    fun log(message: String) {

        println("[$tag] $message")

    }

}

使用示例：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch(CoroutineLogger("Test")) {

        val logger = coroutineContext[CoroutineLogger]

        logger?.log("Start")

        delay(5000)

        logger?.log("End")

    }

    job.join()

}

运行结果：

[Test] Start

[Test] End

coroutineScope() 与 withContext()

coroutineScope 串行的异常封装器

coroutineScope 是一个挂起函数，它会挂起当前协程，直到执行完内部的所有代码（包括会等待内部启动的所有子协程执行完毕），最后一行代码的执行结果会作为函数的返回值。

coroutineScope 会创建一个新的 CoroutineScope，在这个作用域中执行 block 代码块。并且这个作用域严格继承了父上下文（coroutineContext），并会在内部创建一个新的 Job，作为父 Job 的子 Job。

coroutineScope 从效果上来看，和 launch().join() 类似。

那么，它的应用场景是什么？

它的应用场景由它的特性决定，有两个核心场景：

withContext 串行的上下文切换器

我们再来看 withContext，其实它和 coroutineScope 几乎一样。

它也是一个串行的挂起函数，也会返回代码块的结果，内部也是启动了一个新的协程。

它和 coroutineScope 的唯一的不同是，withContext 允许我们传递上下文。你也可以这么想，coroutineScope 就是一个不改变任何上下文的 withContext：

withContext(EmptyCoroutineContext) { // 沿用旧的 CoroutineContext



}



withContext(coroutineContext) { // 使用旧的 CoroutineContext



}

而 withContext 的使用场景就很清楚了，我们需要切换上下文的时候会使用它，并且希望代码是串行执行的，之后还能再切回原来的线程继续往下执行。

虽然 withContext 与 coroutineScope 类似，但 coroutineScope 更多用于封装业务异常。

suspend fun getUserProfile() {

    // 当前在 Dispatchers.Main

    val profile = withContext(Dispatchers.IO) {

        // 自动切换到 IO 线程

        Thread.sleep(3000) // 耗时操作

        "the user profile"

    }



    // 自动切回 Dispatchers.Main

    println("the user profile is $profile")

}

CoroutineContext 的加、取操作

加法：合并与替换

两个 CoroutineContext 相加调用的是 plus()。

public operator fun plus(context: CoroutineContext): CoroutineContext =

    if (context === EmptyCoroutineContext) this else // fast path -- avoid lambda creation

        context.fold(this) { acc, element ->

            val removed = acc.minusKey(element.key)

            if (removed === EmptyCoroutineContext) element else {

                // make sure interceptor is always last in the context (and thus is fast to get when present)

                val interceptor = removed[ContinuationInterceptor]

                if (interceptor == null) CombinedContext(removed, element) else {

                    val left = removed.minusKey(ContinuationInterceptor)

                    if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else

                        CombinedContext(CombinedContext(left, element), interceptor)

                }

            }

        }

其中关键在于 CombinedContext，它是 CoroutineContext 的实现类：

// CoroutineContextImpl.kt

@SinceKotlin("1.3")

internal class CombinedContext(

    private val left: CoroutineContext,

    private val element: Element // Element 也是 `CoroutineContext` 的实现类

) : CoroutineContext, Serializable 

它会将操作符两边的上下文使用 CombinedContext 对象包裹（合并），如果两个上下文具有相同的 Key，加号右侧的会替换左侧的。

比如 Dispatchers.IO + Job() + CoroutineName("my-name") 一共会进行三次合并，得到三个 CombinedContext 对象，不会进行替换。

fun main() = runBlocking<Unit> {

    val handler = CoroutineExceptionHandler { _, throwable ->

        println("Caught $throwable")

    }

    val job =

        launch(Dispatchers.IO + Job() + CoroutineName("my-name") + handler) { 

            println(coroutineContext)

        }

    job.join()

}

运行结果：

[CoroutineName(my-name), com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

如果在末尾再加上一个 CoroutineName("your_name")，会进行一次替换，运行结果是：[com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, CoroutineName(your_name), StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

[] 取值

[] 取值其实调用的是 CoroutineContext.get() 函数，它会从上下文（CombinedContext 树）中找到我们需要的信息。

@SinceKotlin("1.3")

public interface CoroutineContext {

    /**

     * Returns the element with the given [key] from this context or `null`.

     */

    public operator fun <E : Element> get(key: Key<E>): E?

        

    // ...

}

我们填入的参数其实是每一个接口的伴生对象 Key，每个伴生对象都实现了 CoroutineContext.Key<T> 接口，并将泛型指定为了当前接口。

以 ContinuationInterceptor 为例：

@SinceKotlin("1.3")

public interface ContinuationInterceptor : CoroutineContext.Element {

    /**

     * The key that defines *the* context interceptor.

     */

    public companion object Key : CoroutineContext.Key<ContinuationInterceptor>

    

    // ...

}

比如我们要获取上下文中的 CoroutineDispatcher，我们可以这样做：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch {

        val dispatcher = coroutineContext[ContinuationInterceptor] as CoroutineDispatcher // 强转

        println("CoroutineDispatcher is $dispatcher")

    }

    job.join()

}

大多数前端开发者在公司里，很少需要直接操心“部署”这件事——那通常是运维或 DevOps 的工作。

但一旦回到个人项目，情况就完全不一样了。写个小博客、搭个文档站，或者搞个 demo 想给朋友看，部署往往成了最大的拦路虎。

常见的选择无非是 Vercel、Netlify 或 GitHub Pages。它们表面上“一键部署”，但细节其实并不轻松：要注册平台账号、要配置域名，还得接受平台的各种限制。国内的一些云服务商（比如阿里云、腾讯云）管控更严格，操作门槛也更高。更让人担心的是，一旦平台宕机，或者因为地区网络问题导致访问不稳定，你的项目可能随时“消失”在用户面前。虽然这种情况不常见，但始终让人心里不踏实。

很多时候，我们只是想快速上线一个小页面，不想被部署流程拖累，有没有更好的方法？

一个更轻的办法

前段时间我发现了一个开源工具 PinMe，主打的就是“极简部署”。

它的使用体验非常直接：

• 不需要服务器


• 不用注册账号


• 在项目目录敲一条命令，就能把项目打包上传到 IPFS 网络


• 很快，你就能拿到一个可访问的地址

实际用起来的感受就是一个字：爽。

整个过程几乎没有繁琐配置，不需要绑定平台账号，也不用担心流量限制或收费。

这让很多场景变得顺手：

• 临时展示一个 demo，不必折腾服务器


• 写了个静态博客，不想搞 CI/CD 流程


• 做了个活动页或 landing page，随时上线就好

以前这些需求可能要纠结“用 GitHub Pages 还是 Vercel”，现在有了 PinMe，直接一键上链就行。

体验一把

接下来看看它在真实场景下的表现：部署流程有多简化？访问速度如何？和传统方案相比有没有优势？

测试项目

为了覆盖不同体量的场景，这次我选了俩类项目来测试：

• 小型项目：fuwari（开源的个人博客项目），打包体积约 4 MB。


• 中大型项目：Soybean Admin（开源的后台管理系统），打包体积约 15 MB。

部署项目

PinMe 提供了两种方式：命令行 和 可视化界面。

这两种方式我们都来试一下。

命令行部署

先全局安装：

npm install -g pinme

然后一条命令上传：

pinme upload <folder/file-path>

比如上传 Soybean Admin，文件大小 15MB：

输入命令之后，等着就可以了：

只用了两分钟，终端返回的 URL 就能直接访问项目的控制页面。还能绑定自己的域名：

点击网站链接就可以看到已经部署好的项目，访问速度还是挺快的：

同样地，上传个人博客也是一样的流程。

部署完成：

可视化部署

不习惯命令行？PinMe 也提供了网页上传，进度条实时显示：

部署完成后会自动进入管理页面：

经过测试，部署速度和命令行几乎一致。

其他功能

历时记录

部署过的网站都能在主页的 History 查看：

历史部署记录：

也可以用命令行：

pinme list

历史部署记录：

删除网站

如果不再需要某个项目，执行以下命令即可：

pinme rm

PinMe 背后的“硬核支撑”

如果只看表层，PinMe 就像一个极简的托管工具。但要理解它为什么能做到“不依赖平台”，还得看看它背后的底层逻辑。

PinMe 的底层依赖 IPFS，这是一个去中心化的分布式文件系统。

要理解它的意义，得先聊聊“去中心化”这个概念。

传统互联网是中心化的：你访问一个网站时，浏览器会通过 DNS 找到某台服务器，然后从这台服务器获取内容。这条链路依赖强烈，一旦 DNS 被劫持、服务器宕机、服务商下线，网站就无法访问。

去中心化的思路完全不同：

• 数据不是放在单一服务器，而是分布在全球节点中


• 访问不依赖“位置”，而是通过内容哈希来检索


• 只要有节点存储这份内容，就能访问到，不怕单点故障

这意味着：

• 更稳定：即使部分节点宕机，内容依然能从其他节点获取。


• 防篡改：文件哪怕改动一个字节，对应的 CID 也会完全不同，从机制上保障了前端资源的完整性和安全性。


• 更自由：不再受制于中心化平台，文件真正由用户自己掌控。

当然，IPFS 地址（哈希）太长，不适合直接记忆和分享。这时候就需要 ENS（Ethereum Name Service）。它和 DNS 类似，但记录存储在以太坊区块链上，不可能被篡改。比如你可以把 myblog.eth 指向某个 IPFS 哈希，别人只要输入 ENS 域名就能访问，不依赖传统 DNS，自然也不会被劫持。

换句话说：

ENS + IPFS = 内容去中心化 + 域名去中心化

前端个人项目瞬间就有了更高的自由度和安全性。

一点初步感受

PinMe 并不是要取代 Vercel 这类成熟平台，但它带来了一种新的选择：更简单、更自由、更去中心化。

如果你只是想快速上线一个小项目，或者对去中心化部署感兴趣，PinMe 值得一试。

• 官网：pinme.eth.limo/


• Github：github.com/glitternetw…

这是一个完全开源的项目，开发团队也会持续更新。如果你在测试过程中有想法或需求，不妨去 GitHub 提个 Issue —— 这不仅能帮助项目成长，也能让它更贴近前端开发的实际使用场景！

前端开发者应该对 Ant Design 不陌生，特别是 React 开发者，antd 应该是组件库的标配了。

近年来随着 AI 的爆火，凡是想要接入 AI 的都想搞一套自己的 AI 交互界面。专注于 AI 场景组件库的开源项目倒不是很多见，近日 antd 宣布推出 Ant Design X 1.0 🚀 ，这是一个基于 Ant Design 的全新 AGI 组件库，使用 React 构建 AI 驱动的用户交互变得更简单了，它可以无缝集成 AI 聊天组件和 API 服务，简化 AI 界面的开发流程。

该项目已在 Github 开源，拥有 1.6K Star！

看了网友的评论，看来大家还是需要的！当前的 Ant Design X 只支持 React 项目，看来 Vue 开发者要羡慕了...

ant-design-x 特性

• 🌈 源自企业级 AI 产品的最佳实践：基于 RICH 交互范式，提供卓越的 AI 交互体验


• 🧩 灵活多样的原子组件：覆盖绝大部分 AI 对话场景，助力快速构建个性化 AI 交互页面


• ⚡ 开箱即用的模型对接能力：轻松对接符合 OpenAI 标准的模型推理服务


• 🔄 高效管理对话数据流：提供好用的数据流管理功能，让开发更高效


• 📦 丰富的样板间支持：提供多种模板，快速启动 LUI 应用开发


• 🛡 TypeScript 全覆盖：采用 TypeScript 开发，提供完整类型支持，提升开发体验与可靠性


• 🎨 深度主题定制能力：支持细粒度的样式调整，满足各种场景的个性化需求

支持组件

以下圈中的部分为 ant-design-x 支持的组件。可以看到主要都是基于 AI Chat 场景的组件设计。现在你可以基于这些组件自由组装搭建一个自己的 AI 界面。

ant-design-x 也提供了一个完整 AI Chat 的 Demo 演示，可以查看 Demo 的代码并直接使用。

更多组件详细内容可参考 组件文档

使用

以下命令安装 @ant-design/x 依赖。

注意，ant-design-x 是基于 Ant Design，因此还需要安装依赖 antd。

yarn add antd @ant-design/x

import React from 'react';

import {

  // 消息气泡

  Bubble,

  // 发送框

  Sender,

} from '@ant-design/x';



const messages = [

  {

    content: 'Hello, Ant Design X!',

    role: 'user',

  },

];

const App = () => (

  <div>

    <Bubble.List items={messages} />

    <Sender />

  </div>

);



export default App;

Ant Design X 前生 ProChat

不知道有没有小伙伴们使用过 ProChat，这个库后面的维护可能会有些不确定性，其维护者表示 “24 年下半年后就没有更多精力来维护这个项目了，Github 上的 Issue 存留了很多，这边只能尽量把一些恶性 Bug 修复”

如上所示，也回答了其和 Ant Design X 的关系：ProChat 是 x 的前生，新用户请直接使用 x，老用户也请尽快迁移到 x。

感兴趣的朋友们可以去试试哦！

题记

生命中的风景千变万化，但我一直在路上。

风雨兼程，不是为了抵达终点，而是为了沿途的风景。

起因

今天闲来无事，翻翻看看之前的项目。

在看到一个项目的时候，项目框架用的是SpringMvc+Spring+Mybatis。项目里面注释时间写的是2018年，时间长了，里面有好多语法现在看起来好麻烦的样子呀！

说有它就有，这不就有一个吗？在Mybatis配置的xml中，有好多where 1=1 拼接Sql的方式,看的人头都大了。想着改一下吧，又一想，代码已经时间长了，如果出现问题找谁，就先不管了。

话是这样说，但在实际工作中，还是会有方法可以代替的，下面我们一起来看看吧！

替换方式

在 MyBatis 中，WHERE 1=1 通常用来在多条件查询情况下下进行SQL 拼接，其目的就是避免在没有条件时出现语法错误。

但这种写法不够优雅，可通过以下方式进行替代：

1. 使用 <where> 标签（推荐）

MyBatis 的 <where> 标签会自动处理 SQL 的 WHERE 语句，移除多余的 AND 或 OR 关键字。

看实例：

<select id="selectUsers" resultType="User"> 

    SELECT * FROM user 

    <where> 

        <if test="username != null and username != ''"> 

            AND username = #{username} 

        </if> 

        <if test="age != null"> 

            AND age = #{age}

        </if> 

    </where> 

</select>

效果说明：

• 当无参数时，此时执行的Sql语句为：SELECT * FROM user


• 当仅传 username 时，此时执行的Sql语句为：SELECT * FROM user WHERE username = ?


• 当传 username 和 age 时，此时执行的Sql语句为：SELECT * FROM user WHERE username = ? AND age = ?

2. 使用 <trim> 标签自定义

<trim> 可更灵活地处理 SQL 片段，通过设置 prefix 和 prefixOverrides 属性模拟 <where> 的功能。

看实例：

<select id="selectUsers" resultType="User">

  SELECT * FROM user

  <trim prefix="WHERE" prefixOverrides="AND |OR ">

    <if test="username != null and username != ''">

      AND username = #{username}

    </if>

    <if test="age != null">

      AND age = #{age}

    </if>

  </trim>

</select>

说明：

• prefix="WHERE"：在条件前添加 WHERE 关键字。


• prefixOverrides="AND |OR "：移除条件前多余的 AND 或 OR。

3. 使用 <choose>、<when>、<otherwise>

类似Java在进行判断中常用的 switch-case语句，此方式适用于多条件互斥的场景。

看实例：

<select id="selectUsers" resultType="User">

  SELECT * FROM user

  <where>

    <choose>

      <when test="username != null and username != ''">

        username = #{username}

      </when>

      <when test="age != null">

        age = #{age}

      </when>

      <otherwise>

        1=1  <!-- 仅在无任何条件时使用 -->

      </otherwise>

    </choose>

  </where>

</select>

4. Java代码判断控制

在 Service 层根据条件动态选择不同的 SQL 语句。

看实例：

public List<User> getUsers(String username, Integer age) {

    if (username != null && !username.isEmpty()) {

        return userMapper.selectByUsername(username);

    } else if (age != null) {

        return userMapper.selectByAge(age);

    } else {

        return userMapper.selectAll();

    }

}

具体方式对比与选择

总结

推荐优先使用 <where> 标签，它能自动处理 SQL 语法，避免冗余代码。只有在需要更精细控制时，才考虑 <trim> 或其他方式。尽量避免在 XML 中使用 WHERE 1=1，保持 SQL 的简洁性和规范性。

展望

世间万物皆美好, 终有归途暖心潮。

在纷繁的世界里，保持内心的宁静与坚定，让每一步都走向完美的结局。

一、前言：当权限判断写满业务代码

几乎所有企业系统，都逃不过“权限”这道关。

从“谁能看”、“谁能改”到“谁能审批”，权限逻辑贯穿了业务的方方面面。

起初，大多数项目使用最常见的 RBAC（基于角色的访问控制） 模型

if (user.hasRole("admin")) {

    documentService.update(doc);

}

逻辑简单、上手快，看似能解决 80% 的问题。

但随着业务复杂度上升，RBAC 很快会失控。

比如你可能遇到以下需求 👇

• “文档的作者可以编辑自己的文档”；


• “同部门的经理也可以编辑该文档”；


• “外部合作方仅能查看共享文档”；


• “项目归档后，所有人都只读”。

这些场景无法用“角色”简单定义，

于是权限判断开始蔓延在业务代码各处，像这样：

if (user.getId().equals(doc.getOwnerId()) 

    || (user.getDept().equals(doc.getDept()) && user.isManager())) {

    // 编辑文档

} else {

    throw new AccessDeniedException("无权限");

}

时间久了，这些判断像杂草一样蔓延。

权限逻辑与业务逻辑纠缠不清，修改一处可能引发连锁反应。

可维护性、可测试性、可演化性统统崩盘。

二、RBAC 的天花板：角色无法描述现实世界

RBAC 的问题在于：它过于静态。

“角色”可以描述一类人，但描述不了上下文。

举个例子：

研发经理能编辑本部门的文档，但不能编辑市场部的。

在 RBAC 下，你只能再创建新角色：

研发经理、市场经理、项目经理……

角色越来越多，最终爆炸。

而现实世界的权限，往往与“属性”有关：

• 用户的部门


• 资源的拥有者


• 操作发生的时间 / 状态

这些动态因素，是 RBAC 无法覆盖的。

于是我们需要一个更灵活的模型 —— ABAC。

三、ABAC：基于属性的访问控制

ABAC（Attribute-Based Access Control） 的核心理念是：

授权决策 = 函数（主体属性、资源属性、操作属性、环境属性）

一句话总结：

ABAC 不关心用户是谁，而关心“用户和资源具有什么属性”。

举例说明：

“用户可以编辑自己部门的文档，或自己创建的文档。”

简单、直观、灵活。

四、引入 JCasbin：让授权逻辑从代码中消失

JCasbin(github.com/casbin/jcas…) 是一个优秀的 Java 权限引擎，支持多种模型（RBAC、ABAC）。

它最大的价值在于：

把授权逻辑从代码中抽离，让代码只负责执行业务。

在 JCasbin 中，我们通过定义：

• 模型文件（model） ：规则框架；


• 策略文件（policy） ：具体规则。

然后由 Casbin 引擎来执行判断。

五、核心实现：几行配置搞定动态权限

模型文件 model.conf

[request_definition]

r = sub, obj, act



[policy_definition]

p = sub_rule, obj_rule, act



[policy_effect]

e = some(where (p.eft == allow))



[matchers]

m = eval(p.sub_rule) && eval(p.obj_rule) && r.act == p.act

策略文件 policy.csv

p, r.sub.dept == r.obj.dept, true, edit

p, r.sub.id == r.obj.ownerId, true, edit

p, true, true, read

解释：

• 同部门可编辑；


• 作者可编辑；


• 所有人可阅读。

在代码中调用

Enforcer enforcer = new Enforcer("model.conf", "policy.csv");



User user = new User("u1", "研发部");

Document doc = new Document("d1", "研发部", "u1");



boolean canEdit = enforcer.enforce(user, doc, "edit");

System.out.println("是否有编辑权限：" + canEdit);

输出：

是否有编辑权限：true

无需任何 if-else，逻辑全在外部配置中定义。

业务代码只需调用 Enforcer，简单又优雅。

六、在 Spring Boot 中实现“无感校验”

实际项目中，我们希望权限校验能“自动触发”，

这可以通过 注解 + AOP 切面 的方式实现。

定义注解

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface CheckPermission {

    String action();

}

编写切面

@Aspect

@Component

public class PermissionAspect {



    @Autowired

    private Enforcer enforcer;



    @Before("@annotation(checkPermission)")

    public void checkAuth(JoinPoint jp, CheckPermission checkPermission) {

        Object user = getCurrentUser();

        Object resource = getRequestResource(jp);

        String action = checkPermission.action();



        if (!enforcer.enforce(user, resource, action)) {

            throw new AccessDeniedException("无权限执行操作：" + action);

        }

    }

}

在业务代码中使用

@CheckPermission(action = "edit")

@PostMapping("/doc/edit")

public void editDoc(@RequestBody Document doc) {

    documentService.update(doc);

}

✅ 授权逻辑彻底从业务中解耦，权限统一由 Casbin 引擎处理。

七、策略动态化与分布式支持

在生产环境中，权限策略通常存储在数据库中，而非文件。

JCasbin 支持多种扩展方式：

JDBCAdapter adapter = new JDBCAdapter(dataSource);

Enforcer enforcer = new Enforcer("model.conf", adapter);

支持特性包括：

• 💽 MySQL / PostgreSQL 等持久化；


• 🔄 Redis Watcher 实现多节点策略热更新；


• ⚡ SyncedEnforcer 支持高并发一致性。

这样修改权限规则就无需重新部署代码，权限即改即生效

八、总结

引入 JCasbin 后，项目结构会发生显著变化👇

最重要的是：新增规则无需改代码。

只要在策略表里加一条记录，就能实现全新的授权逻辑。

权限系统的复杂，不在于“能不能判断”，

而在于——“判断逻辑放在哪儿”。

当项目越做越大，你会发现：

真正的架构能力，不是多写逻辑，而是让逻辑有边界。

JCasbin 给了我们一个极好的解法：

一个统一的决策引擎，让权限系统既灵活又有秩序。

它不是银弹，但能让你在权限处理上的代码更纯净、系统扩展性更好。

github.com/yuboon/java…

前言

人类的悲喜并不相通，有人欢喜有人愁，更多的是看热闹。

就在上周，"苟住"群里的一个小伙伴也苟不住了。

在苟友们的"墙裂"要求下，他分享了他的经验，以他的视角看看他是怎么操作的。

1. 组织变动，意外晋升

两年前加入公司，依然是一线搬砖的码农。

干到一年的时候公司空降了一位号称有诸多大厂履历的大佬来带领研发，说是要给公司带来全新的变化，用技术创造价值。

大领导第一件事：抓人事，提效率。

在此背景下，公司不少有能力的研发另谋出处，也许我看起来人畜无害，居然被提拔当了小组长。

2. 领取任务，开启副本

当了半年的小组长，我的领导就叫他小领导吧，给我传达了大领导最新规划：团队需要保持冲劲，而实现的手段就是汰换。

用人话来说就是：

当季度KPI得E的人，让其填写绩效改进目标，若下一个季度再得到E，那么就得走人

我们绩效等级是ABCDE，A是传说中的等级，B是几个人有机会，大部分人是C和D，E是垫底。

而我们组就有两位小伙伴得到了E，分别是小A和小B。

小领导意思是让他们直接走得了，大不了再招人顶上，而我想着毕竟大家共事一场，现在大环境寒气满满，我也是过来人，还想再争取争取。

于是分析了他们的基本资料，他俩特点还比较鲜明。

小A资料：

1. 96年，单身无房贷


2. 技术栈较广，技术深度一般，比较粗心


3. 坚持己见，沟通少，有些时候会按照自己的想法来实现功能

小B资料：

1. 98年，热恋有房贷


2. 技术基础较薄弱，但胜在比较认真


3. 容易犯一些技术理解上的问题

了解了小A和小B的历史与现状后，我分别找他们沟通，主要是统一共识：

1. 你是否认可本次绩效评估结果？


2. 你是否认可绩效改进的点与风险点（未达成被裁）？


3. 你是否还愿意在这家公司苟？

最重要是第三点，开诚布公，若是都不想苟了，那就保持现状，不要浪费大家时间，我也不想做无用功。

对于他们，分别做了提升策略：

对于小A：

1. 每次开启需求前都要求其认真阅读文档，不清楚的地方一定要做记录并向相关人确认


2. 遇到比较复杂的需求，我也会一起参与其中梳理技术方案


3. 需求开发完成后，CR代码看是否与技术方案设计一致，若有出入需要记录下来，后续复盘为什么


4. 给足时间，保证充分自测

对于小B：

1. 每次需求多给点时间，多出的时间用来学习技术、熟悉技术


2. 要求其将每个需求拆分为尽可能小的点，涉及到哪些技术要想清楚、弄明白


3. 鼓励他不懂就要问，我也随时给他解答疑难问题，并说出一些原理让他感兴趣的话可以继续深究


4. 分配给他一些技术调研类的任务，提升技术兴趣点与成就感

3. 结束？还是是另一个开始？

半年后...

好消息是：小A、小B的考核结果是D，达成了绩效改进的目标。

坏消息是：据说新的一轮考核算法会变化，宗旨是确保团队血液新鲜（每年至少得置换10%的人）。

随缘吧，我尽力了，也许下一个是我呢？

导语

本文从日常值班问题排查痛点出发，分析方法复用的调用链路和上下文业务逻辑，通过思考分析，借助栈帧开发了一个方法调用栈的链式跟踪工具，便于展示一次请求的方法串行调用链，有助于快速定位代码来源和流量入口，有效提升研发和运维排查定位效率。期望在大家面临类似痛点时可以提供一些实践经验和参考，也欢迎大家合适的场景下接入使用。



现状分析

在系统值班时，经常会有人拿着报错截图前来咨询，作为值班研发，我们则需要获取尽可能多的信息，帮助我们分析报错场景，便于排查识别问题。

例如，下图就是一个常见的的报错信息截图示例。

从图中，我们可以初步获取到一些信息：

•菜单名称：变更单下架，我们这是变更单下架操作时的一个报错提醒。

•报错信息：序列号状态为离库状态，请检查。

•其他辅助信息：例如用户扫描或输入的86开头编码，SKU、商品名称、储位等。

这时会有一些常见的排查思路：

1、根据提示，将用户输入的86编码，按照提示文案去检查用户数据，即作为序列号编码，去看一下序列号是否存在，是否真的是离库了。

2、如果86编码确实是序列号，而且真的是离库了，那么基本上可以快速结案了，这个86编码确实是序列号并且是已离库，正如提示文案所示，这时跟提问人做好解释答疑即可。

3、如果第2步排查完，发现86编码不是序列号编码，或并非离库状态，即与提示文案不符，这时就要定位报错文案的代码来源，继续查看代码逻辑来进行判案了。（这种也比较常见，一种是报错场景较多，但提示文案比较单一，不便于在提示文案中覆盖所有报错场景；另一种提示文案陈旧未跟随需求演变而更新。这两点可以通过细分场景细化对应的报错文案，或更新报错文案，使得报错文案更优更新，但不是本文讨论的重点。）

4、如何根据报错文案快速找到代码来源呢？一般我们会在代码库中搜索提示文案，或者在日志中检索报错信息，辅助定位代码来源，后者依赖于代码中打印了该报错信息，且日志级别配置能够确保该信息打印到日志文件中。

5、倘若我们根据提示文案搜索代码时，发现该提示文案有多处代码出现，此时就较为复杂了，我们需要进一步识别，哪个才与本次报错直接有关。







每个方法向上追溯，又发现调用来源众多：

















在业务复杂的系统中，方法复用比较常见，不同的上下文和参数传递，也有着不同的业务逻辑判断和走向。

这时，基本上进入到本文要讨论的痛点：如何根据有限的提示信息快速定位代码来源？以便于分析报错业务场景，答疑解惑或快速处理问题。

屏幕前的小伙伴，如果你也经常值班排查问题，应该也会有类似的痛点所在。

启发

这是我想到了Exception异常机制，作为一名Coder，我们对异常堆栈再熟悉不过了，异常堆栈是一个“可爱”又“可恨”的东西，“可爱”在于异常堆栈确实可以帮助我们快速定位问题所在，“可恨”在于有异常基本上就是有问题，堆栈让我们审美疲劳，累觉不爱。

下面是一个Java语言的异常堆栈信息示例：







异常类体系和异常处理机制在本文中不是重点，不做过多赘述，本文重点希望能从异常堆栈中获取一些启发。

让我们近距离再观察一下我们的老朋友。

在异常堆栈信息中，主要有四类信息：

•全限定类名

•方法名

•文件名

•代码行号

这四类信息可以帮助我们有效定位代码来源，而且堆栈中记录行先后顺序，也表示着异常发生的第一现场、第二现场、第三现场、……，以此传递。

这让我想起了JVM方法栈中的栈帧。

每当一个方法被调用时，JVM会为该方法创建一个新的栈帧，并将其压入当前线程的栈（也称为调用栈或执行栈)中。栈帧包含了方法执行所需的所有信息，包括局部变量、操作数栈、常量池引用等。







思路

从Java中的Throwable中，可以看到staceTrace的get和set，这个StackTraceElement数组里面存放的信息就是我们在异常堆栈中经常看到的信息。



















再次放一下这张图，方便对照着看。







StackTraceElement类的注释中赫然写着：

StackTraceElement represents a stack frame.

对，StackTraceElement代表着一个栈帧。

这个StackTraceElement就是我要找的东西，即使非异常情况下，每个线程在执行方法调用时都会记录栈帧信息。







按照方法调用先后顺序，将调用栈中方法依次串联起来，就像糖葫芦一样，就可以得到我想要的方法调用链了。

NEXT，我可以动工写个工具了。

工具开发

工具的核心代码并不复杂，StackTraceElement 也是 Java JDK 中现成的，我所做的工作主要是从中过滤出必要的信息，加工简化成，按照顺序整理成链式信息，方便我们一眼就可以看出来方法的调用链。







入参介绍

pretty： 表示是只拼接类和方法，不拼接文件名和行号，非 pretty 是四个都会拼接。

simple： 表示会过滤一些我们代码中场景的代理增强出来的方法的信息输出。

specifiedPrefix： 指定保留相应的包路径堆栈信息，去掉一些过多的中间件信息。

其他还会过滤一些常见代理的堆栈信息：

•FastClassBySpringCGLIB

•EnhancerBySpringCGLIB

•lambda$

•Aspect

•Interceptor

对此，还封装了一些默认参数的方法，使用起来更为方便。







还有一些其他工具方法也可以使用：







使用效果

1、不过滤中间件、代理增强方法的调用栈信息

Thread#run ==> ThreadPoolExecutorWorker#run ==> ThreadPoolExecutor#runWorker ==> BaseTask#run ==> JSFTask#doRun ==> ProviderProxyInvoker#invoke ==> FilterChain#invoke ==> SystemTimeCheckFilter#invoke ==> ProviderExceptionFilter#invoke ==> ProviderContextFilter#invoke ==> InstMethodsInter#intercept ==> ProviderContextFiltereone$auxiliary$9f9kd21#call ==> ProviderContextFilter#eone$original$invoke$p882ot3$accessor$eone$pclcbe2 ==> ProviderContextFilter#eone$original$invokep882ot3 ==> ProviderGenericFilter#invoke ==> ProviderUnitValidationFilter#invoke ==> ProviderHttpGWFilter#invoke ==> ProviderInvokeLimitFilter#invoke ==> ProviderMethodCheckFilter#invoke ==> ProviderTimeoutFilter#invoke ==> ValidationFilter#invoke ==> ProviderConcurrentsFilter#invoke ==> ProviderSecurityFilter#invoke ==> WmsRpcExceptionFilter#invoke ==> WmsRpcExceptionFilter#invoke4provider ==> AdmissionControlJsfFilter#invoke ==> AdmissionControlJsfFilter#providerSide ==> AdmissionControlJsfFilter#processRequest ==> ChainedDeadlineJsfFilter#invoke ==> ChainedDeadlineJsfFilter#providerSide ==> JsfPerformanceMonitor#invoke ==> AbstractMiddlewarePerformanceMonitor#doExecute ==> PerformanceMonitorTemplateComposite#execute ==> PerformanceMonitorTemplateComposite#lambdaexecute0 ==> PerformanceMonitorTemplateUmp#execute ==> PerformanceMonitorTemplateComposite#lambdaexecute0 ==> PerformanceMonitorTemplatePayload#execute ==> JsfPerformanceMonitor#lambdainvoke0 ==> JsfPerformanceMonitor#doInvoke ==> ProviderInvokeFilter#invoke ==> ProviderInvokeFilter#reflectInvoke ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1704#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor344#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1276#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1642#invoke ==> MagicAspect#magic ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1295#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor868#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AnnotationAwareRetryOperationsInterceptor#invoke ==> RetryOperationsInterceptor#invoke ==> RetryTemplate#execute ==> RetryTemplate#doExecute ==> RetryOperationsInterceptor1#doWithRetry ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxyCglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> CglibAopProxyDynamicAdvisedInterceptor#intercept ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> ExposeInvocationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor1276#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> TransactionInterceptor#invoke ==> TransactionAspectSupport#invokeWithinTransaction ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> AspectJAroundAdvice#invoke ==> AbstractAspectJAdvice#invokeAdviceMethod ==> AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs ==> Method#invoke ==> DelegatingMethodAccessorImpl#invoke ==> GeneratedMethodAccessor869#invoke ==> MethodInvocationProceedingJoinPoint#proceed ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> PersistenceExceptionTranslationInterceptor#invoke ==> CglibAopProxyCglibMethodInvocation#proceed ==> ReflectiveMethodInvocation#proceed ==> CglibAopProxy$CglibMethodInvocation#invokeJoinpoint ==> MethodProxy#invoke ==> StackTraceUtils#trace

2、指定包路径过滤中间件后的调用栈栈信息

LockAspect#lock ==> StockTransferAppServiceImpl#increaseStock ==> MonitorAspect#monitor ==> StockRetryExecutor#operateStock ==> StockRetryExecutor$FastClassBySpringCGLIB$5188d6e#invoke ==> BaseStockOperation$FastClassBySpringCGLIB$9d76cd9a#invoke ==> StockTransferServiceImpl$FastClassBySpringCGLIB$85bb181e#invoke ==> ValidationAspect#logAndReturn ==> LogAspect#log ==> ThreadLocalRemovalAspect#removal ==> ValidationAspect#validate ==> BaseStockOperation#go ==> StockRepositoryImpl$EnhancerBySpringCGLIB$1388ef12#operateStock ==> StockTransferAppServiceImpl$EnhancerBySpringCGLIB$1095eafa#increaseStock ==> StockRepositoryImpl$FastClassBySpringCGLIB$a1b4dae4#invoke ==> StockTransferServiceImpl#increaseStock ==> DataBaseExecutor#execute ==> StockRetryExecutor$EnhancerBySpringCGLIB$b42789a#operateStock ==> StockInitializer$EnhancerBySpringCGLIB$85faf510#go ==> StockTransferServiceImpl$EnhancerBySpringCGLIB$afc21975#increaseStock ==> StockRepositoryImpl#operateStock ==> DataBaseExecutor#operate ==> StockTransferAppServiceImpl$FastClassBySpringCGLIB$e348d8e1#invoke

3、去掉Spring代理增强之后的调用栈信息

LogAspect#log ==> LockAspect#lock ==> ValidationAspect#validate ==> ValidationAspect#logAndReturn ==> MonitorAspect#monitor ==> StockTransferAppServiceImpl#decreaseStock ==> ThreadLocalRemovalAspect#removal ==> StockTransferServiceImpl#decreaseStock ==> StockOperationLoader#go ==> BaseStockOperation#go ==> DataBaseExecutor#operate ==> DataBaseExecutor#execute ==> StockRetryExecutor#operateStock ==> StockRepositoryImpl#operateStock

4、去掉一些自定义代理之后的调用栈栈信息

StockTransferAppServiceImpl#increaseStock ==> StockTransferServiceImpl#increaseStock ==> BaseStockOperation#go ==> DataBaseExecutor#operate ==> DataBaseExecutor#execute ==> StockRetryExecutor#operateStock ==> StockRepositoryImpl#operateStock

5、如果带上文件名和行号后的调用栈栈信息

StockTransferAppServiceImpl#increaseStock(StockTransferAppServiceImpl.java:103) ==> StockTransferServiceImpl#increaseStock(StockTransferServiceImpl.java:168) ==> BaseStockOperation#go(BaseStockOperation.java:152) ==> BaseStockOperation#go(BaseStockOperation.java:181) ==> BaseStockOperation#go(BaseStockOperation.java:172) ==> DataBaseExecutor#operate(DataBaseExecutor.java:34) ==> DataBaseExecutor#operate(DataBaseExecutor.java:64) ==> DataBaseExecutor#execute(DataBaseExecutor.java:79) ==> StockRetryExecutor#operateStock(StockRetryExecutor.java:64) ==> StockRepositoryImpl#operateStock(StockRepositoryImpl.java:303)



线上应用实践





接入方法调用栈跟踪工具后，根据报错提示词，可以检索到对应日志，从 ImmediateTransferController#offShelf ==> AopConfig#pointApiExpression ==> TransferOffShelfAppServiceImpl#offShelf ==> TransferOffShelfAppServiceImpl#doOffShelf 中顺藤摸瓜可以快速找到流量入口的代码位置。















适用场景

该方法调用栈工具类，可以在一些堆栈信息进行辅助排查分析的地方进行预埋，例如：

•业务异常时输出堆栈到日志信息中。

•业务监控告警信息中加入调用栈信息。

•一些复用方法调用复杂场景下，打印调用栈信息，展示调用链，方便分析。

•其他一些场景等。

延伸

在《如何一眼定位SQL的代码来源：一款SQL染色标记的简易MyBatis插件》一文中，我发布了一款SQL染色插件，该插件目前已有statementId信息，还支持通过SQLMarkingThreadLocal传递自定义附加信息。其他BGBU的技术小伙伴，也有呼声，希望在statementId基础上可以继续追溯入口方法。通过本文引入的方法调用栈跟踪工具，我在SQL染色插件中增加了方法调用栈染色信息。

SQL染色工具新版特性，欢迎大家先在TEST和UAT环境尝鲜试用，TEST和UAT环境验证没问题后，再逐步推广正式环境。

升级方法：

1、sword-mybatis-plugins版本升级至1.0.8-SNAPSHOT。

2、同时新引入本文的工具依赖

<!-- http://sd.jd.com/article/45616?shareId=105168&isHideShareButton=1 -->

<dependency>

    <groupId>com.jd.sword</groupId>

    <artifactId>sword-utils-common</artifactId>

    <version>1.0.3-SNAPSHOT</version>

</dependency>

3、mybatis config xml 配置文件按最新配置调整

<!-- http://sd.jd.com/article/42942?shareId=105168&isHideShareButton=1 -->

<!-- SQLMarking Plugin，放在第一个Plugin的位置，不影响其他组件，但不强要求位置，也可以灵活调整顺序位置 -->

<plugin interceptor="com.jd.sword.mybatis.plugin.sql.SQLMarkingInterceptor">

    <!-- 是否开启SQL染色标记插件 -->

    <property name="enabled" value="true"/>

    <!-- 是否开启方法调用栈跟踪 -->

    <property name="stackTraceEnabled" value="true"/>

    <!-- 指定需要方法调用栈跟踪的package，减少信息量，value配置为自己工程的package路径，多个路径用英文逗号分割 -->

    <property name="specifiedStackTracePackages" value="com.jdwl.wms.stock"/>

    <!-- 忽略而不进行方法堆栈跟踪的类名列表，多个用英文逗号分割，减少信息量 -->

    <property name="ignoredStackTraceClassNames" value=""/>

    <!-- 结合CPU利用率和性能考虑，方法调用栈跟踪采集率配置采集率，配置示例: m/n，表示n个里面抽m个进行采集跟踪 -->

    <!-- 预发环境和测试环境可以配置全采集，例如配置1/1，生产环境可以结合CPU利用率和性能考虑按需配置采集率 -->

    <property name="stackTraceSamplingRate" value="1/2"/>

    <!-- 是否允许SQL染色标记作为前缀，默认false表示仅作为后缀 -->

    <property name="startsWithMarkingAllowed" value="false"/>

    <!-- 方法调用栈跟踪最大深度，减少信息量 -->

    <property name="maxStackDepth" value="10"/>

</plugin>



或代码配置方式

/**

     * SQLMarking Plugin

     * http://sd.jd.com/article/42942?shareId=105168&isHideShareButton=1

     *

     * @return

     */

    @Bean

    public SQLMarkingInterceptor sQLMarkingInterceptor() {

        SQLMarkingInterceptor sQLMarkingInterceptor = new SQLMarkingInterceptor();

        Properties properties = new Properties();

        // 是否开启SQL染色标记插件

        properties.setProperty("enabled", "true");

        // 是否开启方法调用栈跟踪

        properties.setProperty("stackTraceEnabled", "true");

        // 指定需要方法调用栈跟踪的package，减少信息量，value配置为自己工程的package路径，多个路径用英文逗号分割

        properties.setProperty("specifiedStackTracePackages", "com.jdwl.wms.picking");

        // 结合CPU利用率和性能考虑，方法调用栈跟踪采集率配置采集率，配置示例: m/n，表示n个里面抽m个进行采集跟踪

        // 预发环境和测试环境可以配置全采集，例如配置1/1，生产环境可以结合CPU利用率和性能考虑按需配置采集率

        properties.setProperty("stackTraceSamplingRate", "1/2");

        // 是否允许SQL染色标记作为前缀，默认false表示仅作为后缀

        properties.setProperty("startsWithMarkingAllowed", "false");

        sQLMarkingInterceptor.setProperties(properties);

        return sQLMarkingInterceptor;

    }

接入效果

SELECT

	id,

	tenant_code,

	warehouse_no,

	sku,

	location_no,

	container_level_1,

	container_level_2,

	lot_no,

	sku_level,

	owner_no,

	pack_code,

	conversion_rate,

	stock_qty,

	prepicked_qty,

	premoved_qty,

	frozen_qty,

	diff_qty,

	broken_qty,

	status,

	md5_value,

	version,

	create_user,

	update_user,

	create_time,

	update_time,

	extend_content

FROM

	st_stock

WHERE

	deleted = 0

	AND warehouse_no = ?

	AND location_no IN(?)

	AND container_level_1 IN(?)

	AND container_level_2 IN(?)

	AND sku IN(?)

	/* [SQLMarking] statementId: com.jdwl.wms.stock.infrastructure.jdbc.main.dao.StockQueryDao.selectExtendedStockByLocation, stackTrace: BaseJmqConsumer#onMessage ==> StockInfoConsumer#handle ==> StockInfoConsumer#handleEvent ==> StockExtendContentFiller#fillExtendContent ==> StockInitializer#queryStockByWarehouse ==> StockInitializer#batchQueryStockByWarehouse ==> StockInitializer#queryByLocationAndSku ==> StockQueryRepositoryImpl#queryExtendedStockByLocationAndSku, warehouseNo: 6_6_601 */

如何接入本文工具？

如果小伙伴也有类似使用诉求，大家可以先在测试、UAT环境接入试用，然后再逐步推广线上生产环境。

1、新引入本文的工具依赖

<dependency>

    <groupId>com.jd.sword</groupId>

    <artifactId>sword-utils-common</artifactId>

    <version>1.0.3-SNAPSHOT</version>

</dependency>

2、使用工具类静态方法

com.jd.sword.utils.common.runtime.StackTraceUtils#simpleTrace()

com.jd.sword.utils.common.runtime.StackTraceUtils#simpleTrace(java.lang.String...)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace()

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(java.lang.String...)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(boolean)

com.jd.sword.utils.common.runtime.StackTraceUtils#trace(boolean, boolean, java.lang.String...)

什么是事件循环？

事件循环是 JavaScript 运行时的一个核心机制，它管理着代码的执行顺序。它是一种机制，用于处理异步操作，事件循环的核心是一个循环，它不断地检查调用栈和任务队列，以确保代码按照正确的顺序执行。

JavaScript 的单线程本质

JavaScript 被设计为单线程语言，这意味着它只有一个调用栈，一次只能执行一段代码。这听起来像是一个限制，但正是这种简单性让 JavaScript 如此易于使用。

console.log('开始'); // 1



setTimeout(() => {

  console.log('定时器回调'); // 3

}, 1000);



console.log('结束'); // 2



// 输出顺序：

// 开始

// 结束

// 定时器回调

事件循环的组成部分

1. 调用栈（Call Stack）

调用栈是 JavaScript 执行代码的地方。当函数被调用时，它会被推入栈顶；当函数返回时，它会从栈顶弹出。

function first() {

  console.log('第一个函数');

  second();

}



function second() {

  console.log('第二个函数');

}



first();

2. 任务队列（Task Queue）

任务队列（也称为宏任务队列）存储着待处理的任务，如：

• setTimeout 和 setInterval 回调


• I/O 操作


• UI 渲染


• 事件处理程序

3. 微任务队列（Microtask Queue）

微任务队列具有更高的优先级，包括：

• Promise 回调（.then(), .catch(), .finally()）


• queueMicrotask()


• MutationObserver

事件循环的工作流程

事件循环遵循一个简单的循环：

console.log('脚本开始'); // 同步代码



setTimeout(() => {

  console.log('setTimeout'); // 宏任务

}, 0);



Promise.resolve()

  .then(() => {

    console.log('Promise 1'); // 微任务

  })

  .then(() => {

    console.log('Promise 2'); // 微任务

  });



console.log('脚本结束'); // 同步代码



// 输出顺序：

// 脚本开始

// 脚本结束

// Promise 1

// Promise 2

// setTimeout

实际应用示例

场景 1：用户交互与数据获取

// 模拟用户点击和API调用

document.getElementById('button').addEventListener('click', () => {

  console.log('点击事件处理'); // 宏任务

  

  // 微任务优先于渲染

  Promise.resolve().then(() => {

    console.log('Promise 在点击中');

  });

  

  // 模拟API调用

  fetch('/api/data')

    .then(response => response.json())

    .then(data => {

      console.log('获取到的数据:', data); // 微任务

    });

});



console.log('脚本加载完成');

场景 2：动画性能优化

// 不推荐的写法 - 可能阻塞渲染

function processHeavyData() {

  const data = Array.from({length: 100000}, (_, i) => i);

  return data.map(x => Math.sqrt(x)).filter(x => x > 10);

}



// 推荐的写法 - 使用事件循环分块处理

function processInChunks(data, chunkSize = 1000) {

  let index = 0;

  

  function processChunk() {

    const chunk = data.slice(index, index + chunkSize);

    

    // 处理当前块

    chunk.forEach(item => {

      // 处理逻辑

    });

    

    index += chunkSize;

    

    if (index < data.length) {

      // 使用 setTimeout 让出控制权，允许渲染

      setTimeout(processChunk, 0);

    }

  }

  

  processChunk();

}

常见陷阱与最佳实践

陷阱 1：阻塞事件循环

// ❌ 避免 - 长时间运行的同步操作

function blockingOperation() {

  const start = Date.now();

  while (Date.now() - start < 5000) {

    // 阻塞5秒

  }

  console.log('操作完成');

}



// ✅ 推荐 - 使用异步操作

async function nonBlockingOperation() {

  await new Promise(resolve => setTimeout(resolve, 5000));

  console.log('操作完成');

}

陷阱 2：微任务递归

// ❌ 可能导致微任务无限循环

function dangerousRecursion() {

  Promise.resolve().then(dangerousRecursion);

}



// ✅ 使用 setImmediate 或 setTimeout 打破循环

function safeRecursion() {

  Promise.resolve().then(() => {

    setTimeout(safeRecursion, 0);

  });

}

现代 JavaScript 中的事件循环

async/await 与事件循环

async function asyncExample() {

  console.log('开始 async 函数');

  

  await Promise.resolve();

  console.log('在 await 之后'); // 微任务

  

  const result = await fetch('/api/data');

  console.log('数据获取完成'); // 微任务

}



console.log('脚本开始');

asyncExample();

console.log('脚本结束');



// 输出顺序：

// 脚本开始

// 开始 async 函数

// 脚本结束

// 在 await 之后

// 数据获取完成

调试技巧

1. 使用 console 理解执行顺序

console.log('同步 1');



setTimeout(() => console.log('宏任务 1'), 0);



Promise.resolve()

  .then(() => console.log('微任务 1'))

  .then(() => console.log('微任务 2'));



queueMicrotask(() => console.log('微任务 3'));



console.log('同步 2');

2. 性能监控

// 测量任务执行时间

const startTime = performance.now();



setTimeout(() => {

  const endTime = performance.now();

  console.log(`任务执行耗时: ${endTime - startTime}ms`);

}, 0);

执行顺序问题

网上很经典的面试题

async function async1 () {

  console.log('async1 start')

  await async2() 

  console.log('async1 end') 

}



async function async2 () {

  console.log('async2')

}



console.log('script start')



setTimeout(function () { 

  console.log('setTimeout')

}, 0)



async1()



new Promise (function (resolve) { 

  console.log('promise1') 

  resolve()

}).then (function () { 

  console.log('promise2')

})



console.log('script end')

输出结果

script start

async1 start

async2

promise1

script end

async1 end

promise2

setTimeout

总结

理解 JavaScript 事件循环对于编写高效、响应迅速的应用程序至关重要。记住这些关键点：

• 同步代码首先执行


• 微任务在同步代码之后、渲染之前执行


• 宏任务在微任务之后执行


• 避免阻塞主线程


• 合理使用微任务和宏任务

掌握事件循环机制将帮助你写出更好的异步代码，避免常见的性能问题，并创建更流畅的用户体验。

希望这篇博客能帮助你更好地理解 JavaScript 的事件循环机制！如果你有任何问题或想法，欢迎在评论区讨论。

最近公司里事儿比较多，项目也比较杂，但是因为公司的项目主要是聚焦OA方面，很多东西可以复用。

比方说：表单、表格、搜索栏等等，这部分现阶段大部分都是各写各的，每个项目因为主要的开发不同，各自维护自己的一份。

但是领导现在觉得还是维护一套组件库来的比较方便，一来是减少重复工作量，提升开发效率，二来是方便新人加入团队以后尽量与老成员开发风格保持一致。

另外还有一个原因是项目内现在有的用AntDesign，有的用ElmentPlus，这些库的样式和UI设计出来的风格不搭，改起来也非常麻烦。

我听见这个提议以后后背冷汗都下来了。

我再跟大家强调一遍，不要封装组件库！

咱们说说为什么：

抬高开发成本

大部分人都感觉封装组件库是降低了开发成本，但实际上大部分项目并非如此，封装组件库大部分时候都是抬高了开发成本。

项目不同，面对的客户不同，需求也就不同，所以无论是客户方的需求还是UI设计稿都存在一定的差别，有些时候差距很大。

针对项目单独进行开发虽然在表面上看起来是浪费了人力资源，重复了很多工作，但是在后期开发和维护过程中会节省非常多的时间。

这部分都是成本。很多时候组件的开发并不是面对产品或者团队的，而是面向项目和客户的。

这也就导致了组件的开发会存在极大的不确定性，一方面是需求的不确定，另一方面是组件灵活度的不确定。

很多时候开发出来的组件库会衍生出N多个版本，切出N多个分支，最后在各个项目中引用，逐渐变成一个臃肿的垃圾代码集合体。

我不相信有人会在自己的项目上改完以后，还把修改的部分根据他人的反馈再进行调整，最后合并到 master 分支上去。

我从未见过有这个操作的兄弟。

技术达不到封装水平

团队内部技术不在一个水平线上，事实上也不可能在一个水平线上。

有些人的技术好，封装出来的组件确实很契合大多数的业务场景，有些人技术稍逊，封装出来的组件就不一定能契合项目。

但是如果你用他人封装的组件，牵扯到定制化需求的时候势必会改造，这时候改造就有可能会影响其他项目。

尤其一种情况，老项目升级，这是组件库最容易出问题的时候。可能上个版本封版的组件库在老项目运行的非常完美，但是需要升级的项目引用新的组件库的时候就会出现很多问题。

大部分程序员其实都达不到封装组件库的水准。

如果想要试一试可以参考ElmentUI老版本代码，自己封装一下Select、Input、Button这几个组件，看看和这些久经考验的开源组件库编码程序员还差多少。

技术负债严重

承接上一个问题，不是团队内每个人的水平都一样，并且每个人的编码风格也都是不一样的。(Ts最大的作用点)

可能组件库建立初期会节省非常多的重复工作，毕竟拿来就用，而且本身就是封装好的，简直可以为自己鼓掌了。

照着镜子问这是哪个天才编写的组件库，简直不要太棒了。

但是随着时间的推移，你会发现这个组件库越来越难用，需要考虑的方面越来越多，受影响的模块越来越多，你会变得越来越不敢动其中的代码。

项目越来越多，组件库中的分支和版本越来越多，团队中的人有些已经离开，有些人刚来，这时候技术负债就已经形成了。

更不要说大部分人没有写技术文档的习惯，甚至是连写注释的习惯都没有，功能全靠看代码和猜，技术上的负债越来越严重，这个阶段组件库离崩塌就已经不远了。

新项目在立项之初你就会本能的排斥使用组件库，但是对于老项目呢？改是不可能改动的，但是不维护Bug又挂在这儿。

那你到底是选择代码能跑，还是选择...

对个人发展不利

有些兄弟觉得能封装组件库，让自己的代码在这个团队，这个公司永远的流传下去，简直是跟青史留名差不多了。以后谁用到这个组件都会看到author后面写着我的名字。

但事实并非如此！

封装出的组件库大部分情况下会让你"青💩留名"，因为后面的每个人用这个组件都会骂，这是哪个zz封装的组件，为啥这么写，这里不应该这么写嘛？

如果你一直呆在这个公司，由你一手搭建的这个组件库将伴随你在这个公司的整个职业生涯。

一时造轮子，一辈子维护轮子！

只要任何人用到你这个组件库，遇到了问题一定会来找你。不管你现在到底有没有在负责这个组件库！

这种通用性的组件库不可能没有问题，但是一旦有了问题找到你，你或者是解决不了，又或者是解决的不及时，都将或多或少的影响你的同事对你的评价。

当所有人都对你封装的这个组件库不满意，并且在开组会的时候提出来因为xx封装的组件库不好使，导致了项目延期，时间一长你的领导会对你有好印象？

结语

希望兄弟们还是要明白，对于一个职场人来说，挣钱最重要，能升上去最重要。其他的所有都是细枝末节，不必太在意。

对于客户和老板而言，能快速交付，把钱挣到手最重要，其他也都是无所谓的小事。

对于咱们自己来说，喜欢折腾是程序员的特质，但是要分清形势。

在 JavaScript 开发中，遵循良好的编程规范对于构建高效、可维护的代码至关重要。它不仅能提升代码的可读性，让团队成员之间更容易理解和协作，还能减少错误的发生，提高开发效率。本文将详细介绍 JavaScript 编程中的一些重要规范。

一、命名规范

变量和函数命名

采用小驼峰命名法，第一个单词首字母小写，后续单词首字母大写。例如firstName用于表示名字变量，getUserName函数用于获取用户名。这种命名方式能够清晰地区分变量和函数，并且让名称具有语义化，便于理解其用途。避免使用单字母或无意义的命名，如a、b等，除非在特定的循环等场景下有约定俗成的用法。

常量命名

常量通常使用全大写字母，单词之间用下划线分隔，比如MAX_COUNT表示最大计数，API_URL表示 API 的链接地址。这样的命名方式能够直观地让开发者知道该变量是一个常量，其值在程序运行过程中不会改变。

二、语法规范

使用严格模式

在脚本或函数的开头添加'use strict';开启严格模式。严格模式下，JavaScript 会进行更严格的语法检查，比如禁止使用未声明的变量，防止意外创建全局变量等常见错误。它有助于开发者养成良好的编程习惯，提高代码的质量和稳定性。

// 严格模式

function strictWithExample() {

    'use strict';

    var obj = { x: 1 };

    // 抛出 SyntaxError

    with (obj) {

        console.log(x);

    }

}

strictWithExample();

语句结束加分号

尽管 JavaScript 在某些情况下可以省略分号，但为了避免潜在的错误和代码歧义，强烈建议在每条语句结束后都加上分号。

例如let num = 5和let num = 5;，前者在一些复杂的代码结构中可能会因为自动分号插入机制而出现意想不到的问题，而后者则明确地表示了语句的结束。

let num = 5

console.log(num)

[1, 2, 3].forEach(function (element) {

    console.log(element);

});

在上述代码中，let num = 5 后面没有分号，由于 [ 是 JavaScript 中的数组字面量符号，同时也可以用于数组的索引访问操作（例如 arr[0]），所以引擎会认为你可能想要对 num 进行某种与数组相关的操作，比如 num[1, 2, 3]（虽然这在语法上是错误的，因为 num 是一个数字，不是数组）。

代码缩进

统一使用 2 个或 4 个空格进行缩进，这能让代码的层次结构一目了然。比如在嵌套的if - else语句、循环语句等结构中，合理的缩进能清晰地展示代码的逻辑关系，使代码更易于阅读和维护。

代码块使用大括号

即使代码块中只有一条语句，也建议使用大括号括起来。例如：

if (condition) {

    doSomething();

}

这样在后续需要添加更多语句到代码块中时，能避免因遗漏大括号而导致的语法错误。

三、比较操作规范

尽量使用===和!==进行比较操作，避免使用==和!=。因为==和!=在比较时会进行类型转换，这可能会带来意外结果。例如'5' == 5会返回true，而'5' === 5会返回false，在实际开发中，明确知道数据类型并使用全等操作符能减少错误的发生。

四、代码结构规范

避免全局变量污染

在 JavaScript 开发中，尤其是构建大型项目时，全局变量带来的问题不容小觑。全局变量如同在公共空间随意摆放的物品，极易引发混乱。在一个复杂项目中，可能有多个开发人员同时工作，不同模块的代码相互交织。如果每个模块都随意创建全局变量，很容易出现命名冲突。

• 例如，一个模块定义了全局变量count用于记录某个操作的次数，另一个模块可能也需要使用count变量来记录其他信息，这就会导致变量值被意外覆盖，引发难以排查的错误。

同时，在大型项目中，代码的维护和调试本身就具有挑战性。全局变量的存在会使问题变得更加棘手。因为全局变量在整个程序的生命周期内都存在，其值可能在程序的任何地方被修改。当出现错误时，开发人员很难确定是哪个部分的代码对全局变量进行了不恰当的修改，增加了调试的难度和时间成本。

模块化

为了解决这些问题，模块化是一种非常有效的手段。通过将相关的功能代码封装在一个模块中，每个模块都有自己独立的作用域。在 JavaScript 中，ES6 引入了模块系统，使用export和import关键字来管理模块的导出和导入。例如，有一个处理用户数据的模块userModule.js：

// userModule.js

const userData = {

    name: '',

    age: 0

};



function setUserName(name) {

    userData.name = name;

}



function getUserName() {

    return userData.name;

}



export { setUserName, getUserName };

在这个模块中，userData和setUserName、getUserName函数都在模块内部作用域中，外部无法直接访问userData。只有通过导出的setUserName和getUserName函数，其他模块才能间接操作userData。在其他模块中使用时，可以这样导入：

// main.js

import { setUserName, getUserName } from './userModule.js';



setUserName('John');

console.log(getUserName()); 

这样就有效地避免了全局变量的使用，降低了命名冲突的风险，同时也使得代码的结构更加清晰，易于维护和调试。

立即执行函数表达式（IIFE）

另一种方式是使用立即执行函数表达式（IIFE）。在 JavaScript 中，通过将函数定义包裹在括号中，并紧接着在后面加上括号进行调用，便形成了一个 IIFE。IIFE 能够创建一个独立的函数作用域，在该作用域内定义的变量和函数均为私有。这就确保了函数内部的变量和函数不会被外部随意访问和修改 。例如：

const app = (function () {

    let privateVariable = 10;



    function privateFunction() {

        console.log('This is a private function.');

    }



    return {

        publicFunction: function () {

            privateFunction();

            console.log('The value of private variable is:', privateVariable);

        }

    };

})();



app.publicFunction(); 

在上述代码中，

• (function () {... })()：在包裹匿名函数的括号后面再添加一对括号()，这对括号用于立即调用前面定义的匿名函数。当 JavaScript 引擎执行到这部分代码时，就会立即调用这个匿名函数，所以称为 “立即执行函数”。


• privateVariable和privateFunction都在 IIFE 内部的私有作用域中，因此外部无法直接访问它们。通过返回一个包含publicFunction的对象，向外暴露了一个公共接口，这样一来既实现了功能，又避免了全局变量污染。

合理使用注释

在关键代码逻辑处添加注释，解释代码的功能、用途、算法思路等。注释要简洁准确，避免过度注释。

• 例如在一个复杂的算法函数前，可以注释说明该算法的作用、输入参数和返回值的含义，方便其他开发者理解代码。


• 但不要在过于简单的代码上添加冗余注释，如let num = 1; // 定义一个数字变量，这样的注释对理解代码没有实质性帮助。

五、注释规范

注释分为单行注释和多行注释。单行注释使用//，用于对某一行代码进行简单解释。多行注释使用/* */，适合对一段代码块进行详细说明。在写注释时，要确保注释与代码同步更新，避免代码修改后注释不再准确的情况。

六、异步编程规范

随着 JavaScript 在前端和后端开发中的广泛应用，异步编程变得越来越重要。使用async/await语法可以让异步代码看起来更像同步代码，提高代码的可读性。例如：

async function getData() {

    try {

        let response = await fetch('https://example.com/api');

        let data = await response.json();

        return data;

    } catch (error) {

        console.error('获取数据失败', error);

    }

}

在处理多个异步操作时，要注意合理控制并发数量，避免因过多并发请求导致性能问题。

七、代码格式化规范

使用代码格式化工具，如 Prettier、ESLint 等，能够自动按照设定的规则对代码进行格式化。它可以统一代码风格，包括缩进、空格、换行等，使团队成员的代码风格保持一致，减少因风格差异带来的冲突和阅读障碍。

八、代码复用

尽量编写可复用的代码，通过函数封装、模块封装等方式，将重复使用的代码逻辑提取出来。

• 例如，在多个地方需要对数据进行格式化处理，可以编写一个通用的数据格式化函数，在需要的地方调用，这样不仅能减少代码量，还方便维护和修改。

九、错误处理

在代码中要合理处理错误，使用try - catch块捕获可能出现的异常。对于异步操作，也要通过try - catch或者.catch方法来处理错误。

• 例如在网络请求失败时，要及时向用户反馈错误信息，而不是让程序崩溃。同时，可以自定义错误类型，以便在不同的业务场景下进行更精准的错误处理。

遵循这些 JavaScript 编程规范，能够帮助开发者写出更整洁、高效、易于维护的代码。在实际开发中，团队可以根据项目需求进一步细化和完善这些规范，以提升整个项目的质量。

大家好，我是程序员鱼皮。我发现很多程序员都不打日志，有的是 不想 打、有的是 意识不到 要打、还有的是 真不会 打日志啊！

前段时间的模拟面试中，我问了几位应届的 Java 开发同学 “你在项目中是怎么打日志的”，得到的答案竟然是 “支支吾吾”、“阿巴阿巴”，更有甚者，竟然表示：直接用 System.out.println() 打印一下吧。。。

要知道，日志是我们系统出现错误时，最快速有效的定位工具，没有日志给出的错误信息，遇到报错你就会一脸懵逼；而且日志还可以用来记录业务信息，比如记录用户执行的每个操作，不仅可以用于分析改进系统，同时在遇到非法操作时，也能很快找到凶手。

因此，对于程序员来说，日志记录是重要的基本功。但很多同学并没有系统学习过日志操作、缺乏经验，所以我写下这篇文章，分享自己在开发项目中记录日志的方法和最佳实践，希望对大家有帮助~

一、日志记录的方法

日志框架选型

有很多 Java 的日志框架和工具库，可以帮我们用一行代码快速完成日志记录。

在学习日志记录之前，很多同学应该是通过 System.out.println 输出信息来调试程序的，简单方便。

但是，System.out.println 存在很严重的问题！

首先，System.out.println 是一个同步方法，每次调用都会导致 I/O 操作，比较耗时，频繁使用甚至会严重影响应用程序的性能，所以不建议在生产环境使用。此外，它只能输出简单的信息到标准控制台，无法灵活设置日志级别、格式、输出位置等。

所以我们一般会选择专业的 Java 日志框架或工具库，比如经典的 Apache Log4j 和它的升级版 Log4j 2，还有 Spring Boot 默认集成的 Logback 库。不仅可以帮我们用一行代码更快地完成日志记录，还能灵活调整格式、设置日志级别、将日志写入到文件中、压缩日志等。

可能还有同学听说过 SLF4J（Simple Logging Facade for Java），看英文名就知道了，这玩意并不是一个具体的日志实现，而是为各种日志框架提供简单统一接口的日志门面（抽象层）。

啥是门面？

举个例子，现在我们要记录日志了，先联系到前台接待人员 SLF4J，它说必须要让我们选择日志的级别（debug / info / warn / error），然后要提供日志的内容。确认之后，SLF4J 自己不干活，屁颠屁颠儿地去找具体的日志实现框架，比如 Logback，然后由 Logback 进行日志写入。

这样做有什么好处呢？无论我们选择哪套日志框架、或者后期要切换日志框架，调用的方法始终是相同的，不用再去更改日志调用代码，比如将 log.info 改为 log.printInfo。

既然 SLF4J 只是玩抽象，那么 Log4j、Log4j 2 和 Logback 应该选择哪一个呢？

值得一提的是，SLF4J、Log4j 和 Logback 竟然都是同一个作者（俄罗斯程序员 Ceki Gülcü）。

首先，Log4j 已经停止维护，直接排除。Log4j 2 和 Logback 基本都能满足功能需求，那么就看性能、稳定性和易用性。

• 从性能来说，Log4j 2 和 Logback 虽然都支持异步日志，但是 Log4j 基于 LMAX Disruptor 高性能异步处理库实现，性能更高。


• 从稳定性来说，虽然这些日志库都被曝出过漏洞，但 Log4j 2 的漏洞更为致命，姑且算是 Logback 得一分。


• 从易用性来说，二者差不多，但 Logback 是 SLF4J 的原生实现、Log4j2 需要额外使用 SLF4J 绑定器实现。

再加上 Spring Boot 默认集成了 Logback，如果没有特殊的性能需求，我会更推荐初学者选择 Logback，都不用引入额外的库了~

使用日志框架

日志框架的使用非常简单，一般需要先获取到 Logger 日志对象，然后调用 logger.xxx（比如 logger.info）就能输出日志了。

最传统的方法就是通过 LoggerFactory 手动获取 Logger，示例代码如下：

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

​

public class MyService {

   private static final Logger logger = LoggerFactory.getLogger(MyService.class);

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

上述代码中，我们通过调用日志工厂并传入当前类，创建了一个 logger。但由于每个类的类名都不同，我们又经常复制这行代码到不同的类中，就很容易忘记修改类名。

所以我们可以使用 this.getClass 动态获取当前类的实例，来创建 Logger 对象：

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

给每个类都复制一遍这行代码，就能愉快地打日志了。

但我觉得这样做还是有点麻烦，我连复制粘贴都懒得做，怎么办？

还有更简单的方式，使用 Lombok 工具库提供的 @Slf4j 注解，可以自动为当前类生成一个名为 log 的 SLF4J Logger 对象，简化了 Logger 的定义过程。示例代码如下：

import lombok.extern.slf4j.Slf4j;

​

@Slf4j

public class MyService {

   public void doSomething() {

       log.info("执行了一些操作");

  }

}

这也是我比较推荐的方式，效率杠杠的。

此外，你可以通过修改日志配置文件（比如 logback.xml 或 logback-spring.xml）来设置日志输出的格式、级别、输出路径等。日志配置文件比较复杂，不建议大家去记忆语法，随用随查即可。

二、日志记录的最佳实践

学习完日志记录的方法后，再分享一些我个人记录日志的经验。内容较多，大家可以先了解一下，实际开发中按需运用。

1、合理选择日志级别

日志级别的作用是标识日志的重要程度，常见的级别有：

• TRACE：最细粒度的信息，通常只在开发过程中使用，用于跟踪程序的执行路径。


• DEBUG：调试信息，记录程序运行时的内部状态和变量值。


• INFO：一般信息，记录系统的关键运行状态和业务流程。


• WARN：警告信息，表示可能存在潜在问题，但系统仍可继续运行。


• ERROR：错误信息，表示出现了影响系统功能的问题，需要及时处理。


• FATAL：致命错误，表示系统可能无法继续运行，需要立即关注。

其中，用的最多的当属 DEBUG、INFO、WARN 和 ERROR 了。

建议在开发环境使用低级别日志（比如 DEBUG），以获取详细的信息；生产环境使用高级别日志（比如 INFO 或 WARN），减少日志量，降低性能开销的同时，防止重要信息被无用日志淹没。

注意一点，日志级别未必是一成不变的，假如有一天你的程序出错了，但是看日志找不到任何有效信息，可能就需要降低下日志输出级别了。

2、正确记录日志信息

当要输出的日志内容中存在变量时，建议使用参数化日志，也就是在日志信息中使用占位符（比如 {}），由日志框架在运行时替换为实际参数值。

比如输出一行用户登录日志：

// 不推荐

logger.debug("用户ID：" + userId + " 登录成功。");

​

// 推荐

logger.debug("用户ID：{} 登录成功。", userId);

这样做不仅让日志清晰易读；而且在日志级别低于当前记录级别时，不会执行字符串拼接，从而避免了字符串拼接带来的性能开销、以及潜在的 NullPointerException 问题。所以建议在所有日志记录中，使用参数化的方式替代字符串拼接。

此外，在输出异常信息时，建议同时记录上下文信息、以及完整的异常堆栈信息，便于排查问题：

try {

   // 业务逻辑

} catch (Exception e) {

logger.error("处理用户ID：{} 时发生异常：", userId, e);

}

3、控制日志输出量

过多的日志不仅会占用更多的磁盘空间，还会增加系统的 I/O 负担，影响系统性能。

因此，除了根据环境设置合适的日志级别外，还要尽量避免在循环中输出日志。

可以添加条件来控制，比如在批量处理时，每处理 1000 条数据时才记录一次：

if (index % 1000 == 0) {

   logger.info("已处理 {} 条记录", index);

}

或者在循环中利用 StringBuilder 进行字符串拼接，循环结束后统一输出：

StringBuilder logBuilder = new StringBuilder("处理结果：");

for (Item item : items) {

   try {

       processItem(item);

       logBuilder.append(String.format("成功[ID=%s], ", item.getId()));

  } catch (Exception e) {

       logBuilder.append(String.format("失败[ID=%s, 原因=%s], ", item.getId(), e.getMessage()));

  }

}

logger.info(logBuilder.toString());

如果参数的计算开销较大，且当前日志级别不需要输出，应该在记录前进行级别检查，从而避免多余的参数计算：

if (logger.isDebugEnabled()) {

   logger.debug("复杂对象信息：{}", expensiveToComputeObject());

}

此外，还可以通过更改日志配置文件整体过滤掉特定级别的日志，来防止日志刷屏：

<!-- Logback 示例 -->

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

<!-- 只允许 INFO 级别及以上的日志通过 -->

   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

       <level>INFO</level>

   </filter>

   <!-- 配置其他属性 -->

</appender>

4、把控时机和内容

很多开发者（尤其是线上经验不丰富的开发者）并没有养成记录日志的习惯，觉得记录日志不重要，等到出了问题无法排查的时候才追悔莫及。

一般情况下，需要在系统的关键流程和重要业务节点记录日志，比如用户登录、订单处理、支付等都是关键业务，建议多记录日志。

对于重要的方法，建议在入口和出口记录重要的参数和返回值，便于快速还原现场、复现问题。

对于调用链较长的操作，确保在每个环节都有日志，以便追踪到问题所在的环节。

如果你不想区分上面这些情况，我的建议是尽量在前期多记录一些日志，后面再慢慢移除掉不需要的日志。比如可以利用 AOP 切面编程在每个业务方法执行前输出执行信息：

@Aspect

@Component

public class LoggingAspect {

​

   @Before("execution(* com.example.service..*(..))")

   public void logBeforeMethod(JoinPoint joinPoint) {

       Logger logger = LoggerFactory.getLogger(joinPoint.getTarget().getClass());

       logger.info("方法 {} 开始执行", joinPoint.getSignature().getName());

  }

}

利用 AOP，还可以自动打印每个 Controller 接口的请求参数和返回值，这样就不会错过任何一次调用信息了。

不过这样做也有一个很重要的点，注意不要在日志中记录了敏感信息，比如用户密码。万一你的日志不小心泄露出去，就相当于泄露了大量用户的信息。

5、日志管理

随着日志文件的持续增长，会导致磁盘空间耗尽，影响系统正常运行，所以我们需要一些策略来对日志进行管理。

首先是设置日志的滚动策略，可以根据文件大小或日期，自动对日志文件进行切分。比如按文件大小滚动：

<!-- 按大小滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.SizeBasedRollingPolicy">

   <maxFileSize>10MB</maxFileSize>

</rollingPolicy>

如果日志文件大小达到 10MB，Logback 会将当前日志文件重命名为 app.log.1 或其他命名模式（具体由文件名模式决定），然后创建新的 app.log 文件继续写入日志。

还有按照时间日期滚动：

<!-- 按时间滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log</fileNamePattern>

</rollingPolicy>

上述配置表示每天创建一个新的日志文件，%d{yyyy-MM-dd} 表示按照日期命名日志文件，例如 app-2024-11-21.log。

还可以通过 maxHistory 属性，限制保留的历史日志文件数量或天数：

<maxHistory>30</maxHistory>

这样一来，我们就可以按照天数查看指定的日志，单个日志文件也不会很大，提高了日志检索效率。

对于用户较多的企业级项目，日志的增长是飞快的，因此建议开启日志压缩功能，节省磁盘空间。

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log.gz</fileNamePattern>

</rollingPolicy>

上述配置表示：每天生成一个新的日志文件，旧的日志文件会被压缩存储。

除了配置日志切分和压缩外，我们还需要定期审查日志，查看日志的有效性和空间占用情况，从日志中发现系统的问题、清理无用的日志信息等。

如果你想偷懒，也可以写个自动化清理脚本，定期清理过期的日志文件，释放磁盘空间。比如：

# 每月清理一次超过 90 天的日志文件

find /var/log/myapp/ -type f -mtime +90 -exec rm {} ;

6、统一日志格式

统一的日志格式有助于日志的解析、搜索和分析，特别是在分布式系统中。

我举个例子大家就能感受到这么做的重要性了。

统一的日志格式：

2024-11-21 14:30:15.123 [main] INFO com.example.service.UserService - 用户ID：12345 登录成功

2024-11-21 14:30:16.789 [main] ERROR com.example.service.UserService - 用户ID：12345 登录失败，原因：密码错误

2024-11-21 14:30:17.456 [main] DEBUG com.example.dao.UserDao - 执行SQL：[SELECT * FROM users WHERE id=12345]

2024-11-21 14:30:18.654 [main] WARN com.example.config.AppConfig - 配置项 `timeout` 使用默认值：3000ms

2024-11-21 14:30:19.001 [main] INFO com.example.Main - 应用启动成功，耗时：2.34秒

这段日志整齐清晰，支持按照时间、线程、级别、类名和内容搜索。

不统一的日志格式：

2024/11/21 14:30 登录成功 用户ID: 12345

2024-11-21 14:30:16 错误 用户12345登录失败！密码不对

DEBUG 执行SQL SELECT * FROM users WHERE id=12345

Timeout = default

应用启动成功

emm，看到这种日志我直接原地爆炸！

建议每个项目都要明确约定和配置一套日志输出规范，确保日志中包含时间戳、日志级别、线程、类名、方法名、消息等关键信息。

<!-- 控制台日志输出 -->

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

   <encoder>

       <!-- 日志格式 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

   </encoder>

</appender>

也可以直接使用标准化格式，比如 JSON，确保所有日志遵循相同的结构，便于后续对日志进行分析处理：

<encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">

   <!-- 配置 JSON 编码器 -->

</encoder>

此外，你还可以通过 MDC（Mapped Diagnostic Context）给日志添加额外的上下文信息，比如用户 ID、请求 ID 等，方便追踪。在 Java 代码中，可以为 MDC 变量设置值：

MDC.put("requestId", "666");

MDC.put("userId", "yupi");

logger.info("用户请求处理完成");

MDC.clear();

对应的日志配置如下：

<!-- 文件日志配置 -->

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <encoder>

       <!-- 包含 MDC 信息 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{requestId}] [%X{userId}] %msg%n</pattern>

   </encoder>

</appender>

这样，每个请求、每个用户的操作一目了然。

7、使用异步日志

对于追求性能的操作，可以使用异步日志，将日志的写入操作放在单独的线程中，减少对主线程的阻塞，从而提升系统性能。

除了自己开线程去执行 log 操作之外，还可以直接修改配置来开启 Logback 的异步日志功能：

<!-- 异步 Appender -->

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

   <queueSize>500</queueSize> <!-- 队列大小 -->

   <discardingThreshold>0</discardingThreshold> <!-- 丢弃阈值，0 表示不丢弃 -->

   <neverBlock>true</neverBlock> <!-- 队列满时是否阻塞主线程，true 表示不阻塞 -->

   <appender-ref ref="CONSOLE" /> <!-- 生效的日志目标 -->

   <appender-ref ref="FILE" />

</appender>

上述配置的关键是配置缓冲队列，要设置合适的队列大小和丢弃策略，防止日志积压或丢失。

8、集成日志收集系统

在比较成熟的公司中，我们可能会使用更专业的日志管理和分析系统，比如 ELK（Elasticsearch、Logstash、Kibana）。不仅不用每次都登录到服务器上查看日志文件，还可以更灵活地搜索日志。

但是搭建和运维 ELK 的成本还是比较大的，对于小团队，我的建议是不要急着搞这一套。

OK，就分享到这里，洋洋洒洒 4000 多字，希望这篇文章能帮助大家意识到日志记录的重要性，并养成良好的日志记录习惯。学会的话给鱼皮点个赞吧~

日志不是写给机器看的，是写给未来的你和你的队友看的！

更多

💻 编程学习交流：编程导航

📃 简历快速制作：老鱼简历

✏️ 面试刷题神器：面试鸭

一.为什么需要理解设计模式？

前端项目会随着需求迭代变得越来越复杂，设计模式的作用就是提前规避 “后期难改、牵一发动全身” 的坑，设计模式的核心价值：解决 “可维护、可扩展” 问题。

1.工厂模式

工厂模式：通过一个统一的 “工厂函数 / 类” 封装对象的创建逻辑，外界只需传入参数（如类型、配置），即可获取所需实例，无需关心实例内部的构造细节。核心是 “创建逻辑与使用逻辑分离”，实现批量、灵活地创建相似对象。

前端应用场景：

1.Axios 实例

2.Vue实例

3.组件库中的 “表单组件工厂”,统一管理所有表单组件的基础属性（如 id、disabled）

2.单例模式：确保全局只有一个实例

核心是为了解决 “重复创建实例导致的资源浪费、状态混乱、逻辑冲突” 问题—— 当某个对象在系统中只需要 “唯一存在” 时，单例模式能确保全局访问到的是同一个实例，从根源避免多实例带来的隐患。

前端典型场景：

1.Vuex单一store实例

2.浏览器的 window 对象

3.原型模式：通过 “复制” 创建新对象

原型模式的核心是 “基于已有对象（原型）复制创建新对象” —— 不是从零开始定义新对象的属性和方法，而是直接 “拷贝” 一个现有对象（原型）的结构，再根据需要修改差异化内容。

前端中原型模式的本质：依托 JavaScript 原型链。

JavaScript 本身就是基于原型的语言，所有对象都有 __proto__ 属性（指向其原型对象），这是原型模式在前端的 “天然实现”。

普通对象原型属性: 只有'proto'属性。

函数原型属性：proto、prototype属性。

prototype：专属属性，只有函数有，用于 "当函数作为构造函数时，给新创建的实例提供原型"。

原型链顶端： Object.prototype.proto :指向null ;

前端典型场景：

1.Object.create()

2.Vue2 的数组方法重写：Vue2 为数组的push、pop等方法添加响应式逻辑，新数组会继承这些重写后的方法。

3.继承

工厂模式与原型模式区别：

工厂模式：

基于参数 / 规则 “全新创建” 对象；

核心目的：封装复杂的创建逻辑，让调用者无需关心对象构造细节。

原型模式

基于 “已有原型对象” 复制生成新对象

核心目的：复用已有对象的属性 / 方法，减少重复定义，支持继承扩展

4.观察者模式：“一对多” 的依赖通知机制

观察者模式（Observer Pattern）是一种 “一对多” 的依赖关系设计模式：

• 存在一个 “被观察者（Subject）” 和多个 “观察者（Observer）”；


• 当被观察者的状态发生变化时，会自动通知所有依赖它的观察者，并触发观察者的更新逻辑；


• 核心是 “解耦被观察者和观察者”—— 双方无需知道彼此的具体实现，只需通过统一的接口通信

前端典型场景：

1.浏览器事件监听（最基础的观察者模式）

浏览器的 DOM 事件本质是观察者模式的实现：

• 被观察者：DOM 元素（如按钮）；


• 观察者：事件处理函数（onclick、onchange 等）；


• 流程：给元素绑定事件（订阅）→ 元素状态变化（如被点击）→ 自动执行所有绑定的事件处理函数（通知观察者）。


• 观察者模式的核心价值是 “状态变化自动同步”

2.状态管理库（Vuex/Pinia/Redux）

Vuex、Redux 等全局状态管理库的核心机制就是观察者模式：

• 被观察者：Store 中的状态（如 state.user、state.cart）；


• 观察者：依赖该状态的组件；


• 流程：组件订阅状态（mapState 或 useSelector）→ 状态更新（commit 或 dispatch）→ 所有订阅该状态的组件自动重新渲染（收到通知更新）

3. 框架的响应式系统（Vue/React）

Vue 的响应式原理（数据驱动视图）和 React 的状态更新机制，底层都依赖观察者模式：

• Vue：数据对象（data）是被观察者，视图（DOM）和计算属性是观察者 —— 数据变化时，Vue 自动触发依赖收集的观察者（视图重新渲染、计算属性重新计算）。


• React：setState 触发状态更新时，组件树中依赖该状态的组件（观察者）会被重新渲染（收到通知执行更新）。

5.发布-订阅模式

发布 - 订阅模式是观察者模式的变体，核心是通过一个 “中间者（事件中心）” 实现 “发布者” 和 “订阅者” 的完全解耦 —— 发布者不用知道谁在订阅，订阅者也不用知道谁在发布，双方仅通过事件中心传递消息，就像 “报社（发布者）→ 邮局（事件中心）→ 订报人（订阅者）” 的关系。

• 三大角色：
  
  
  
  
  1. 发布者（Publisher） ：负责 “发布事件”（比如触发某个状态变化，如用户登录、数据更新），但不直接联系订阅者；
  
  
  2. 订阅者（Subscriber） ：负责 “订阅事件”（比如关注 “用户登录” 事件），并定义事件触发时的 “回调逻辑”（比如登录后显示欢迎信息）；
  
  
  3. 事件中心（Event Bus） ：中间枢纽，负责存储 “事件 - 订阅者” 的映射关系，接收发布者的事件并通知所有订阅者。
  
  
  
  


• 核心逻辑：订阅者先在事件中心 “订阅” 某个事件 → 发布者在事件中心 “发布” 该事件 → 事件中心找到所有订阅该事件的订阅者，触发它们的回调。

与观察者模式区别：

前端典型场景：

1.跨组件通信（事件总线 Event Bus）

2.全局状态管理（如 Redux 的 Action 机制）

• 发布者：组件通过 dispatch(action) 发布 “状态变更事件”；


• 事件中心：Redux 的 Store，存储状态并管理订阅者；


• 订阅者：组件通过 store.subscribe(() => { ... }) 订阅状态变化，状态更新时重新渲染。

状态管理库到底是观察者模式还是发布 - 订阅模式？

状态管理库（如 Vuex、Redux）之所以会让人觉得 “既是观察者模式，又是发布 - 订阅模式”，是因为它们融合了两种模式的核心思想—— 在底层实现上，既保留了观察者模式 “状态与依赖直接关联” 的特性，又通过 “中间层” 实现了发布 - 订阅模式的 “解耦” 优势，本质是两种模式的结合与优化。

1. 底层：状态与组件的 “观察者模式”（直接依赖）

状态管理库中， “全局状态” 与 “依赖该状态的组件”  之间是典型的观察者模式：

• 被观察者：全局状态（如 Vuex 的 state、Redux 的 store）；


• 观察者：订阅了该状态的组件；


• 逻辑：当状态发生变化时，会直接通知所有依赖它的组件（观察者），触发组件重新渲染。

这一层的核心是 “精准依赖”—— 组件只订阅自己需要的状态（比如 Vue 的 mapState、Redux 的 useSelector），状态变化时只有相关组件会被通知，避免无效更新。

2. 上层：组件与状态的 “发布 - 订阅模式”（解耦通信）

状态管理库中， “组件触发状态变更” 与 “状态变更通知组件”  的过程，通过 “中间层（如 commit/dispatch）” 实现，类似发布 - 订阅模式：

• 发布者：触发状态变更的组件（通过 store.commit('increment') 或 dispatch(action) 发布 “状态变更事件”）；


• 事件中心：状态管理库的核心逻辑（如 Vuex 的 Store 实例、Redux 的 dispatch 机制）；


• 订阅者：依赖状态的组件（通过 subscribe 或计算属性订阅状态）。

这一层的核心是 “解耦”—— 组件不需要知道谁会处理状态变更，也不需要知道哪些组件依赖该状态；状态管理库作为中间层，接收 “发布” 的变更请求，处理后再 “通知” 订阅者，双方完全隔离。

6.代理模式

代理模式（Proxy Pattern）是一种 “通过中间代理对象控制对原始对象的访问” 的设计模式 —— 不直接操作目标对象，而是通过一个 “代理” 来间接访问，代理可以在访问前后添加额外逻辑（如权限校验、缓存、日志记录等）。

核心作用：“控制访问” 与 “增强功能”

前端典型场景：

1. 权限控制代理（限制访问）

2.Vue3响应式核心

用 “中间商” 的思路理解 Vue3 响应式：

• 目标对象：你定义的 data 数据（如 { count: 0, user: { name: '张三' } }）；


• 代理对象：Vue3 通过 reactive() 或 ref() 创建的 “响应式代理”（本质是 Proxy 实例）；


• 调用者：组件中的模板（视图）或业务逻辑（如 {{ count }} 或 count.value++）；


• 代理的 “附加操作” ：拦截数据的读取（get）和修改（set），在读取时 “收集依赖”（记录哪些地方用到了这个数据），在修改时 “触发更新”（通知依赖的地方重新渲染）。

1. 目标对象：原始数据 const target = { count: 0 }; 

2. 依赖收集的容器：记录哪些函数依赖了数据（比如视图渲染函数）

const deps = new Set(); 

3. 创建代理对象（核心：拦截读写，添加响应式逻辑） 

const reactiveProxy = new Proxy(target, 

{

// 拦截“读取数据”操作（如访问 count 时）

get(target, key){

    // 附加操作1：

    收集依赖（假设当前正在执行的函数是依赖） 

    if (currentEffect) { deps.add(currentEffect); // 把依赖存起来 } 

    return target[key]; // 返回原始值 }, 

}

 // 拦截“修改数据”操作（如 count++ 时） 

set(target, key, value) { 

// 更新原始数据 

target[key] = value; 

// 附加操作2：触发更新（通知所有依赖重新执行） 

deps.forEach(effect => effect()); return true; } }); 

}

扩展：Vue3响应式对比vue2响应式

1.Vue2 用的是 Object.defineProperty 拦截属性，只能拦截已存在的属性（对新增属性、数组索引修改不友好）；

具体原因拆解：

Object.defineProperty 的工作方式是给对象的某个具体属性添加 getter/setter。

但数组本质是特殊对象（属性是索引，如 arr[0]、arr[1]），如果用 Object.defineProperty 拦截数组，只能逐个拦截索引（如 0、1），但存在两个致命问题：

1.问题一：无法拦截数组的原生方法（push/pop/splice 等）
数组的常用操作（如 push 新增元素、splice 删除元素）是通过调用数组原型上的方法实现的，这些方法会直接修改数组本身，但 Object.defineProperty 无法拦截 “方法调用”，只能拦截 “属性读写”。所以最终Vue2采取了这7个数组方法的重写。

 arrayMethods[method] = function(...args) {

    // 先调用原生方法（比如 push 实际添加元素）

    const result = arrayProto[method].apply(this, args);

    // 手动触发更新（通知依赖重新渲染）

    notifyUpdate(); 

    return result;

2.问题二：拦截数组索引的成本极高，且不实用。

• 初始化成本高：数组长度可能很大（甚至动态变化），提前拦截所有索引会浪费性能；


• 数组长度变化无法拦截：
  当 arr.length = 0 时，数组会清空所有元素（即删除索引 0、1、2），但 Object.defineProperty 只能知道 length 被改成了 0，无法知道具体哪些元素被删除了。

对于响应式系统来说，需要知道 “哪些元素变化了” 才能精准通知依赖这些元素的视图。但 length 拦截只能知道 “长度变了”，无法定位具体变化的元素，导致依赖这些元素的视图可能不会更新（比如某个视图依赖 arr[0]，length=0 后 arr[0] 不存在了，但视图可能还显示旧值）。

2.Vue3 用 Proxy 直接代理整个对象，能拦截所有属性的读写（包括新增、删除、数组操作），是更彻底、更灵活的代理模式实现，这也是 Vue3 响应式比 Vue2 强大的核心原因之一。

总结

最后想强调：设计模式不是必须遵守的 “规则”，而是解决问题的 “工具”。在实际开发中，我们不需要刻意追求 “用满所有模式”，而是根据场景选择合适的工具：

• 需批量创建对象 → 工厂模式


• 需全局唯一实例 → 单例模式


• .....

参考文章：juejin.cn/post/754253…

最近阅读Android源码，很多地方都涉及到了线程的概念，比如BootAnimation，应用层的线程倒是略懂一二，Framework的线程却是知之甚少，因此特此记录如下：

Android的Native层thread的实现方案一般有两种：

• Linux上的posix线程方案


• Native层面封装的Thread类（用的最多）

posix线程方案

首先创建空文件夹项目-Linux_Thread

其次在Linux_Thread文件夹下创建一个文件thread_posix.c:主要逻辑是在主线程中创建一个子线程mythread，主线程等待子线程执行完毕后，退出进程：

#include <pthread.h>

#include <stdio.h>

#include <stdlib.h>

#include <utils/Log.h>



//线程执行逻辑

void *thread_posix_function(void *arg)

{

	(void*) arg;

	int i;

	for(i = 0; i < 40; i++)

	{

		printf("hello thread i + %d\n", i);

		ALOGD("hello thread i + %d\n", i);

		sleep(1);

	}

	return NULL;

}



int main(void)

{

	

	pthread_t mythread;

	//创建线程并执行

	if(pthread_create(&mythread, NULL, thread_posix_function, NULL))

	{

		ALOGD("error createing thread");

		abort();

	}

	

	sleep(1);

	//等待mythread线程执行结束

	if(pthread_join(mythread, NULL))

	{

		ALOGD("error joining thread");

		abort();

	}

	ALOGD("hello thread has run end exit\n");

	//退出

	exit(0);

}