最近有个业务需求，需要去小红书开放平台对接一些报表数据接口，通过定时任务，在每天特定的时间点拉取效果数据并落库。

对接第三方接口需要遵守他们的规则。小红书接口单页允许的 page_size 最大为 100，这就意味着，如果有 100 万条数据，那么就需要做 1 万次 “拉取-落库” 的动作。单线程去做的话会非常耗时，因此需要利用 Go 并发编程的特性去多线程并发。

让 Claude 4.5 Opus 实现功能之后，发现它使用了一种叫 Worker Pool (工作池) 的并发模式，通过 Gemini 进行学习了解后，发现这是 Go 中一种非常经典且高效的并发设计模式，正好最近刚学习完 Goroutine、Channel、sync.WaitGroup 等概念，Worker Pool 是一个综合的实践，而且 Worker Pool 的示例代码虽然看上去一眼就懂，但其实有很多细节我发现自己并没有完全理解（记录在了最后的 FAQ 章节），因此打算做一个记录~

Worker Pool 的核心思想

Gemini 的一句话总结和举例，我觉得非常完美，做到了 “多则惑，少则缺”，因此直接照抄过来。

Worker Pool 的核心思想是：提前创建固定数量的 Goroutine（工作协程），让它们竞争式地从一个任务队列中获取并处理任务。

就像是一个工厂的流水线，无论有多少订单（任务），流水线上只有固定数量的工人（Worker）在干活。

为什么需要 Worker Pool？

虽然 Goroutine 非常轻量（仅需 2KB 内存，作为对比，操作系统线程需要 2MB），但在处理海量任务时，如果直接为每个任务创建一个新的 Goroutine（还是前文的例子，假设有 100 万条数据，但每次最多只能拉取 100 条，如果为每个拉取 100 条数据的任务创建一个 Goroutine，那么就需要同时创建 1 万个），会产生以下问题：

• 资源耗尽： 瞬时创建上万个 Goroutine 可能导致内存溢出。
• 上下文切换开销： 过多 Goroutine 会增加 CPU 调度器的负担。
• 缺乏控制： 难以限制对下游资源（如数据库连接、API 调用）的并发访问。

Worker Pool 通过 “复用” 和 “限额” 解决了这些问题。

核心结构

一个典型的 Worker Pool 由三个部分组成：

• Job Queue (任务队列)： 通常是一个 channel，用于存放待处理的任务。
• Worker (工人)： 一组在后台循环运行的 Goroutine。
• Result Queue (结果队列)： 可选，用于收集处理后的结果。

graph LR    Generator[Job Generator
任务生成者] -->|Enqueue| JobQueue[Job Queue
任务队列]        subgraph WorkerPool [Worker Pool 工作池]        W1[Worker 1]        W2[Worker 2]        W3[Worker ...]    end        JobQueue -->|Fetch| W1    JobQueue -->|Fetch| W2    JobQueue -->|Fetch| W3        W1 -->|Result| ResultQueue[Result Queue
结果队列]    W2 -->|Result| ResultQueue    W3 -->|Result| ResultQueue        ResultQueue -->|Collect| Collector[Result Collector
结果收集者]        style JobQueue fill:#ffeb3b,stroke:#333,stroke-width:2px;    style ResultQueue fill:#4caf50,stroke:#333,stroke-width:2px;    style WorkerPool fill:#e3f2fd,stroke:#333,stroke-dasharray: 5 5;

Talk is cheap, show me the code!

一个简单的流程示意图，对应后续代码中的执行步骤：

graph TD    %% 主流程节点    Init[1. 初始化通道] --> Start[2. 启动 5 个 Worker]    Start --> Send[3. 发送 1000 个任务]    Send --> CloseJobs[关闭 Job 通道]        %% 后台逻辑    Start -.->|后台运行| Worker[Worker: 抢任务 -> 处理 -> 存结果]        %% 监控与收集    CloseJobs --> Monitor[Monitor: 等待 Worker 全部结束]    Monitor --> CloseRes[关闭 Result 通道]    CloseRes --> Collect[4. 收集结果]        %% 数据流向示意    Worker -.->|处理结果| Collect        style Worker fill:#e1f5fe,stroke:#01579b    style Monitor fill:#fff9c4,stroke:#fbc02d

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

package main

import (
    "fmt"
    "sync"
    "time"
)


/**
 * worker 函数：对应「核心结构」章节中的 Worker，从 jobs 通道读任务，处理后发给 results 通道
 * @param id      工人编号
 * @param jobs    只读通道 (<-chan)：工人只能从这里拿任务
 * @param results 只写通道 (chan<-)：工人只能把结果往这里放
 * @param wg      计数器：用来告诉主程序自己什么时候干完活
 */
func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
    // defer 保证即使函数中途出错，也会在退出前执行 Done()，避免主线程死锁
    defer wg.Done()

    // range 会不断从 jobs 中取数据，直到 jobs 通道被 close(jobs) 且数据取完
    for j := range jobs {
        fmt.Printf("Worker %d 开始处理任务 %d\n", id, j)

        // 模拟耗时的真实业务逻辑（如调用小红书 API、读写数据库）
        time.Sleep(time.Second)

        // 处理完后将结果放入结果通道
        results <- j * 2
        fmt.Printf("工人 %d: 完成任务 %d\n", id, j)
    }
}

func main() {
    const numJobs = 1000 // 假设一共有 1000 个任务
    const numWorkers = 5 // 限制并发数为 5（控制压力），最多只有 5 个 worker 同时处理，可以灵活配置

    // 初始化【任务通道】和【结果通道】
    jobs := make(chan int, numJobs) // 对应「核心结构」章节中的 Job Queue (任务队列)：通常是一个 channel，用于存放待处理的任务
    results := make(chan int, numJobs) // 对应「核心结构」章节中的 Result Queue (结果队列)：可选，用于收集处理后的结果

    var wg sync.WaitGroup

    // 1. 启动指定数量的 worker，目前数量是 5 
    // 此时工人已经就绪，但在 jobs 通道没数据前，他们都会阻塞在 range 那行 “待命”
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }

    // 2. 发送任务到队列
    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }

    // 【关键点】任务发完了，一定要关闭 jobs 通道
    // 关闭后，workers 里的 range 循环在取完剩余任务后会自动结束
    close(jobs)

    // 3. 监控完成情况 (开启一个“收尾”协程)
    go func() {
        wg.Wait() // 等待所有工人退出
        close(results) // 所有人都干完了，结果通道也可以关了
    }()

    // 4. 收集结果
    for res := range results {
        fmt.Println("结果:", res)
    }

    fmt.Println("所有任务处理完毕！")
}

FAQ

那些我发现一开始并没有完全理解的点。

1. 为什么 jobs 和 results 都要初始化成有缓冲区的通道 (Buffered Channel)？

如果没有缓冲区，发一个任务就必须立刻有一个工人接走，否则发送者就会卡在那动弹不得。

有了缓冲区，主程序可以先把 1000 个任务一股脑丢进暂存区，然后去干别的事。工人根据自己的节奏慢慢拿，这样能极大提高吞吐量，解耦了“发任务”和“做任务”的速度差异。

2. 在发送任务结束后就立刻 close(jobs)，那如果 jobs 内的数据还没有被处理，不会出问题吗？

不会。 这是 Go Channel 的重要特性：

• 关闭通道仅仅意味着：以后不会再有新任务进来了。
• 已经在通道里的任务（缓冲区里的）依然可以被正常读取。
• 工人们读完缓冲区里的最后一个任务后，for j := range jobs 就会自动结束循环。

3. 为什么 wg.Wait() 和 close(results) 要单独放在一个 Goroutine 里？

这是为了避免“死锁”。

主程序运行到 for res := range results 时会一直等着拿数据。

工人们一直在往 results 塞数据。

如果你在主程序里写 wg.Wait()，主程序会卡在这里等工人干完。但如果工人因为 results 通道满了（且没人从里面拿走）而阻塞，他们就永远干不完。

结果： 工人在等主程序拿数据，主程序在等工人干完活。谁也不让谁，程序就“卡死”了。单独开一个协程监控收尾，可以保证主程序能立刻开始处理结果。

4. 多个 worker 并发从 jobs 里取数据，不会出现取到同一个任务的情况吗？

绝对不会。

Go 的 Channel 底层有锁机制（加锁的环形链表），它是并发安全的。

就像一个自动售货机，无论多少人同时扫码买最后一瓶水，最终只会有一个人拿到，售货机内部会保证数据的原子性。

TODO

这两块内容在需求中没有设计，目前只停留在理论阶段，等实践过了再更新到正文。

1. 如果其中一个任务导致 Worker Panic（崩溃）了怎么办？

问题： 默认情况下，一个 Goroutine 崩溃会导致整个进程退出。
解决： 在 worker 函数内部使用 recover()。在 Worker Pool 中，通常需要捕获异常，打印日志，并调用 wg.Done()，否则 Wait() 永远等不到结束，程序会死锁。

2. 如何优雅地“提前关闭” Worker Pool？

场景： 比如用户点击了取消按钮，或者遇到了严重错误，不想跑剩下的 1 万个任务了。
技巧： 仅仅 close(jobs) 是不够的，因为工人可能正阻塞在某个耗时操作上。这时候需要引入 context.Context。给工人传入一个 ctx，在函数内通过 select { case <-ctx.Done(): return } 来实现秒级的停止。

对 JavaScript Runtime 的正确认识

对于 JavaScript，我们常说 JS 有一个调用栈 (call stack)、有一个事件循环机制 (Event Loop)、有一个任务/回调队列 (task/callback queue) 以及一些 WebAPI，但这等价于 V8 也拥有以上这些东西吗？

答案是：并非如此。

以 V8 为例，简单来看，它其实只包含一个堆 (heap) 和一个调用栈 (call stack)。

如果 clone 一下 V8 的源码，会发现 setTimeout、DOM、HTTP Request 这些东西都是不在 V8 的源码中的。

也就是说，V8 并不包括 Event Loop、callback queue 和其他的 WebAPIs。

由上图可以看出，JS 的浏览器运行环境包含三部分:

• V8 (JavaScript Runtime)
• 浏览器提供的 WebAPIs (DOM、AJAX、setTimeout…)
• callback queue

这三者互相配合，共同实现了 Event Loop。

The call stack

one thread === one call stack === one thing at a time

JavaScript 是一门单线程语言，也就是只有一个调用栈，即一次只能做一件事。

blocking 阻塞

What happens when things are slow?

慢的东西会阻塞调用栈

什么是慢的/快的东西？以下是一些直观的理解：

• console.log 不慢
• 从 0 到 100亿 做一个 while 循环是慢的
• 网络请求是慢的

假设所有的 network request 都是同步（串行）的，那我们要等待每一个请求都结束之后，才能运行其他的代码。

Why is this a problem? because, browsers.

blocking 会成为一个问题的一大原因，就是因为我们是在浏览器里运行代码。

而阻塞性的代码，会卡住 call stack，从而阻塞页面的渲染。

the solution? asynchronous callbacks

Here's a function. Call me maybe?

以这段简单的代码为例，执行到 setTimeOut 时，其中的 callback 就好像从 call stack 消失了一样。然后 5s 之后，又神奇地回到了 call stack 中，并被执行，其中到底有什么奥秘呢？

Concurrency & the Event Loop

One thing at a time, except not really?

JavaScript Runtime 确实一次只能做一件事。但浏览器，并不只有 JavaScript Runtime。

还是以 setTimeout 为例，正如上文提到的，setTimeout 并不存在于 runtime 中，而是由浏览器的提供的 WebAPI。

setTimeout 接收一个 callback 和一个 delay，当执行到 setTimeout 时，便由 WebAPI 接管了（上文提到过，setTimeout 并不存在于 V8 源码中），在 WebAPI 接管后，setTimeout 本身会 pop 出 call stack。

WebAPI 提供了计时器的功能，当 delay 的时间到了之后，WebAPI 并不会直接把 callback 塞到 call stack 中（如果真是如此的话，那 callback 很可能会突然地出现在正在执行的代码里，这肯定是不对的）。

事实是，浏览器还提供了一个任务队列（回调队列），当倒计时结束后，这个 callback 将会进入这个队列中，等待进入 call stack。

这个时候，也就是 Event Loop 正式出场的时候。

Event Loop 做的事情非常简单：看一眼 call stack，如果空了，那就从任务队列中取出第一个任务，塞到 call stack 中去执行。

这个时候就得提到经典的 setTimeout(callback, 0) 了，通过上面的介绍，我们可以了解到这样写的目的，就是为了在 call stack 被清空的时候，才去执行 callback。

AJAX 也是同理，AJAX 并不存在于 V8 中，而是由浏览器提供。请求的过程由 WebAPI 接手，因此并不会阻塞 call stack。即使这个请求永远不结束，也不会阻塞其他代码的执行 & 浏览器的渲染。

Event Listener 也是同理。以 $.on(‘button’, ‘click’, callback) 为例。WebAPIs 将会接手 click 事件的注册，当 click 发生时，WebAPIs 将会向任务队列中推入一个 callback。

Event Loop 是如何配合浏览器渲染的？

在 call stack 不为空时，浏览器是无法渲染的。

可以把 render 也看作是一个 callback，有一个专门的 render queue，它的优先级比 task queue 更高。

以 60 帧为例，每 16.6ms，浏览器就会把一个 render 加到 render queue （优先级更高的队列）中，但要等到 call stack 清空时，再进行 render。

我们常说的“不要阻塞事件循环”，就是指不要在栈上执行又臭又长的同步代码，因为这样一来，浏览器就无法渲染了。

　　最近在做一个 H5 工具，需要手机号 + 验证码登录，很自然地，点击发送验证码后需要等待一段时间才能重新发送，用于请求节流，避免用户疯狂点击：

　　不过这里其实有个隐藏需求——如果仍然在冷却时间内，那么用户无论是刷新或是关闭页面，再次打开登录弹窗，需要直接展示正确的倒计时状态。

解决方案

使用经典的 localStorage：
· 发送验证码时，将发送时间 (lastSendingTime) 存入 localStorage，并开启 60 秒倒计时。
· 倒计时结束后，清除 localStorage 中的 lastSendingTime。
· 重新进入页面时，若 localStorage 中存有 lastSendingTime，则说明仍处于冷却时间内，那么计算出剩余的倒计时 N，并开启 N 秒倒计时。

Talk is cheap, show me the code!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

  const [countdown, setCountdown] = useState(60) // 倒计时
  const [canSendCode, setCanSendCode] = useState(true) // 控制按钮文案的状态
  const [timer, setTimer] = useState() // 定时器 ID

  async function sendVerificationCode() {
    try {
      // network request...
      Toast.show({ content: '验证码发送成功' })
      startCountdown()
      setCanSendCode(false)
    } catch (error) {
      setCountdown(0)
      setCanSendCode(true)
    }
  }

  function startCountdown() {
    const nowTime = new Date().getTime()
    const lastSendingTime = localStorage.getItem('lastSendingTime')
    if (lastSendingTime) {
      // 若 localStorage 中存有 lastSendingTime，则说明仍处于冷却时间内，计算出剩余的 countdown
      const restCountdown = 60 - parseInt(((nowTime - lastSendingTime) / 1000), 10)
      setCountdown(restCountdown <= 0 ? 0 : restCountdown)
    } else {
      // 否则说明冷却时间已结束，则 countdown 为 60s，并将发送时间存入 localStorage
      setCountdown(60)
      localStorage.setItem('lastSendingTime', nowTime)
    }

    setTimer(
      setInterval(() => {
        setCountdown(old => old - 1)
      }, 1000),
    )
  }

  // 重新进入页面时，若 localStorage 中存有上次的发送时间，则说明还处于冷却时间内，则调用函数计算剩余倒计时；否则什么也不做
  useEffect(() => {
    const lastSendingTime = localStorage.getItem('lastSendingTime') 
    if (lastSendingTime) {
      setCanSendCode(false)
      startCountdown()
    }

    return () => {
      clearInterval(timer)
    }
  }, [])

  
  /** 监听倒计时，倒计时结束时:
   * - 清空 localStorage 中存储的上次发送时间
   * - 清除定时器
   * - 重置倒计时
  */
  useEffect(() => {
    if (countdown <= 0) {
      setCanSendCode(true)
      localStorage.removeItem('lastSendingTime')
      clearInterval(timer)
      setCountdown(60)
    }
  }, [countdown])

return (
  {canSendCode ? (
    <span onClick={sendVerificationCode}>
      获取验证码
    </span>
  ) : (
    <span>
      获取验证码({`${countdown}`})
    </span>
  )}
)

最终效果

总结

　　一开始感觉这是个很简单的小需求，可能 20min 就写完了，但实际花了两个多小时才把逻辑全部 cover 到，还是不能太自信啊~

JavaScript

Event Loop I

Event Loop II

React

A (Mostly) Complete Guide to React Rendering Behavior

　　最近开发遇到了一个很 tricky 的问题，直接上 gif，看了就明白了：

　　可以明显看到，在搜狗拼音输入法还没有完成输入的时候就已经触发搜索了，此时根据拼音内容(一些英文)去搜索，会搜索不到任何结果，导致 Table 内显示空信息。

　　这明显不是我们想要的效果，我们所希望的应该是在输入法完成输入（按下空格或回车）后，再去触发搜索框的搜索。

解决方案

onCompositionStart & onCompositionEnd

　　这两个事件确实第一次接触，以 compositionstart event 为例：

　　简单来说，搜狗拼音输入法就是图中所说的 IME(Input Method Editor) ，当开启一段 composition session 的时候就会触发这个事件，至于什么是 composition session 呢~

　　知道有这个 event 之后，一切也就豁然开朗了，我们可以引入一个 lock 变量，通过 onCompositionStart & onCompositionEnd 来维护；当且仅当 lock 为 false 的时候才触发搜索~

（伪）代码

1
2
3
4
5

<Input
  onChange={e => setInputVal(e.target.value)}
  onCompositionStart={() => setLock(true)}
  onCompositionEnd={() => setLock(false)}
/>

1
2
3
4

useEffect(() => {
  // 输入拼音的情况下，选择了文字才搜索，正在输入拼音时不触发搜索
  !lock && triggerSearch(inputVal);
}, [lock, inputVal]);

最终效果

总结

　　之前我一直以为这不是个前端范畴的问题，是系统层面的，事实证明还是认知局限呀🤣今后还是要多多学习，多多记录。

　　​这段时间有太多想记录分享的，但随着相册里的照片越积越多却又一直没整理，原本设想的月度复盘最终演变成了这样一篇转正综述😝。

 
　　​简单 self review 了一下，相比五个月前的自己，最大的进步来自于四个方面:

对 Stack Overflow、GitHub 等社区的使用

　　​本科期间对这些社区的使用仅限于嫖开源项目，现在逐渐能根据业务导向去探索一些解决方案了，也慢慢能够将宽泛的业务需求总结成一个个 one-sentence question 去寻找一些最佳实践。相比从前只能在 CSDN 的屎山里遨游，似乎感觉自己慢慢有 web developer 的感觉了🤣。

面对业务难题的心态

　　如果要选这五个月来最难的一个需求，我觉得是贡献度页面的 PDF 下载——用从未使用过的库(html2canvas & jspdf)去完成一个定制化很高的需求。
　　拆开看其实就是两个大难点——从未使用过 & 定制化很高。
　　前者还好，只需要花时间去读文档试 API；但对于后者，则意味着网上不会有完全可以参照的解决方案。

　　官方文档的目的是用最简示例让你明白核心 API 的用法，但如何去组合可用的几十上百个 API 来完成业务需求，这个是官方文档没法 cover 到的。记得刚开始做的时候确实毫无头绪，后来真的是某个瞬间突然有了想法：html2canvas 是基于 DOM node 的，那我结合业务需求去手动控制 DOM node 是不是就可以了呢？后来尝试了一个简单的 case 发现确实可以！
　　有了大方向，后面去磨逻辑就可以了，细节会非常多，但到了这个阶段，其实已经演变成了和第一个难点同一级别的问题了——花时间就可以解决的问题，俗称体力活🤣。
　　这个需求完成之后，有种完成进化的感觉。

　　quote 一下关于这件事的微博，记录了我的思考：

　　最近刚做完一个比较特殊的导出 PDF 需求，用的两个库都是第一次接触( html2canvas & jspdf )，一路上遇到了不少坑，最后都摸索着解决了。作为一个喜欢复盘的人，本来想着好好复盘一下这两个库的使用流程，但是后来好像就突然醒悟了：为什么要去细抠这两个库呢，在未来十几年开发生涯里用到这两个库的次数大概率屈指可数，真正有价值的其实是那些坑，是那些开发过程中的瓶颈，或者说，是跨过坑和迈过瓶颈的思考过程和处理方法。
　　其实是一个很简单的道理，相比聚焦于某个具体问题。作为一名工程师，需要培养的其实是解决问题的能力。从而达到一种 mentality:

• 任何问题都有解决的方法
• 我遇到的问题也是
• 我一定可以解决它

​bug 的分析 & 调试

　　这点或许就是所谓的经验，开发年限久了，见识的场景多了，改 bug 的能力就自然而然提升了。
　　就我的例子而言，反映在​对组件渲染、状态流动、异步有了更深的认识，所以打断点越来越准确，定位问题越来越快了。
　　此外，也离不开其他前端家人们的 code review 与 comments，我在解决完一些比较 tricky 的 bug 的时候都会尽可能把心路历程和来龙去脉写在 commit message 里，我觉得能把原因-分析-解决的链路描述清楚，才算真正地吃透了这个 bug；此外，一般的 code review 大家只会看代码的风格是否可以优化，没太多时间去细究内部的业务逻辑(大家手头都有活)，但有了比较详尽的 description 之后能让 reviewer 更好地理解场景，有时他们会提供一些更好的思路，让我发现其实是我搞复杂了。

技术文档的书写

　　像大字版和埋点这两个需求，我算是前端的 owner，从调研技术实现，到这两个模块的基建，再到书写文档和各位前端家人一起维护，有体验到一种 leadership 的感觉，是一种从未有过的体验😁。

　　包括在做某个功能的时候需要复用一个很复杂的组件，在确定复用方案上我也接受了紫月老师的建议，写了篇文档把两种方式做了对比，最终和大家讨论选取了一个更适合的方案。

　　把零碎的思路形成易于接受的、有条理的文字是一件很浪漫的事情。(顺便感叹一句飞书文档真的好用，国庆去敦煌做了份攻略，一开始用的是 Google Docs，不是很顺手，换飞书文档之后体验大大提升，强烈安利😋)

End

　　下班之后​随手写了点，anyway，保持热爱，继续前进!

　　即使消息一直在发酵，我还是相对乐观，因为那些爆料人也说了，秒针(我们部门)作为独立的核心部门，是不会有大动作的。

　　而且，我去提前实习了近四个月，如期完成了布置给我的所有开发任务，出色地融入了团队，就算真的要毁约一批校招生，相比那些没去提前实习的同学，我也有绝对的优势能够留下。
　　最后，也是一丝侥幸心理，6 月份了，即使公司再没有人性，也做不出在毕业前两个礼拜毁约的举动吧，这不仅是毁人前途，也是断人后路。
　　但还是发生了，击碎了我最后的幻想。

　　好笑的是，在被毁约的前一天，我都还在为相同遭遇的应届生们抱不平。

　　7 号下午我处在崩溃的边缘，我的理性压制着杂乱稀碎的情绪，我努力告诉自己，去消化这个消息，去做对当下最好的决定。
　　我在找一个可以发泄的点，尝试将这个结果归咎于我的某一个错误决定或举动，但我找不到。
　　从去年 3 月份开始，我刷了五十多套视频，背了无数的面经八股，从 9.7 第一场面试开始，20 天拿到了 3 份 offer，10.9 明略正式给我开了 30k 的意向书，我觉得秋招圆满收官了，也拒绝了此后的所有笔面试流程。

　　我开始帮朋友们辅导面试、和他们分享学习路线、解决群友们的开发问题。这份 offer 让我保持着学习的热情，让我愿意放弃最后的校园生活去公司提前适应。公司的一切也让我无比满意，顶级的办公环境、前沿的技术栈、扁平的团队氛围、还有知无不言、贴心带着我成长的 mentor。

　　我曾经跑在前面，但一个解约电话和一份违约金让我回到了起点。
　　这就是绝境了吧？秋招的另外两份 offer 询问后被告知已经没有 hc 了，形势本就惨淡的春招完全结束，补录也所剩无几，即使还有面试机会，实习之后的我专注于业务，用来应付笔面试的八股文和算法也已淡忘生疏。
　　更何况，离毕业只有 20 天了，要去公司办离职手续，走毁约流程，要去了解封校期间的就业办政策，处理毕业事宜，要投简历，要去捡起淡忘的八股文和算法，我问自己，这怎么可能办得到呢。
　　曾经的野心和理想开始反噬我，我从未陷入过这个程度的自我怀疑。
　　晚上，我收拾了一下情绪，开始检索各个招聘平台，牛客、毕业申、智联、boss，我投递了所有还能投递的公司。
　　8 号醒的时候天还黑着，看了眼手机 4 点多，但没有了睡意，起床开始看秋招时的面经和笔记。上午开始陆续有 hr 联系我。第一个面试在下午两点半，五位面试官，持续一个多小时，一面过。晚上七点，另一家公司，将近一个小时，一面过。我屏蔽了所有的社交媒体，不让自己的思绪有一丝空闲，我怕那种随之而来的窒息感。
　　随着 9 号两场面试的通过，我的状态好些了，但更开心的是遇到了心仪的公司：在淮海中路，位置热闹、技术栈前沿，leader 是保送交大的竞赛生，hr 给我分享了他的博客，映入眼帘的第一篇：《那个喊了十三声发物资的邻居》，翻到最下面，看到一篇 2013 年的文章：《妈的，交大》，我的第一感觉：他是个有趣的人。面试的时候他也让我感受到了一种和那些生硬地问一个个技术问题的面试官不同的感觉。腾讯会议里还有另一位女生，他告诉我，这位女生本科也是交大，硕士在密歇根大学，同样是今年的校招生，如果我加入，以后大家就是同一个 team 了，我说，我喜欢和优秀的人在一起。在我一面通过并表达强烈的加入愿景之后，他也承诺会为我加快推进流程。
　　9 号晚上做完了笔试，10号下午 cto 面 + hr 面，晚上 6 点半等来了 offer call。
　　放下手机，也许是这几天没怎么休息，有些恍惚。两天前我以为最终的结局或许就是要去国企或者某个小厂冒着野心和技术慢慢被消磨的风险去沉淀（如果消磨太多的话或许是沉沦？）两三年，幸好，现在又有了在互联网泥沼里摸爬滚打的机会。我联系了其他几家的 hr，表示已经接到了合适的 offer，也对他们表达了最诚挚的感谢，在这个时间点给了我面试的机会，让我不至于沉浸在惶恐却什么都做不了的绝望情绪里。
　　这几天也让我明确了一些事，好像也就两件，第一件就是去搭一个博客，我会把这篇放上去，作为第一篇文章。我突然联想到高中，当时想着要写写日记，但一直没开始，后来第一次下笔是在 2015.11.11，因为那天月考还是期中考成绩出来了，我数学没及格，很伤心，突然就有了下笔的冲动，没想到就坚持了下来，每天晚自修的最后十分钟写个几行，坚持了三年。或许这次也是个开始的契机吧。说到这个就想起来日记本还在上大寝室的架子上，不知道啥时候才能回去搬寝室。
　　第二件事情就是，应该再也没有过不去的坎了，至少我现在是这样觉得的。
　　还有很多事情要处理，先写到这吧。

　　今天做一个 Modal 的时候，需要修改 antd Form 的一些默认样式。一开始感觉没啥问题，用 Chrome DevTools 在页面上找到 antd 组件内相应的元素，修改对应的 class 达到效果后复制到了 VSCode 里，但是，页面完全没有变化！！！！！！！

　　钻了 20 分钟没解决，赶紧去问 mentor, 津铭哥笑着和我说需要在外层加一个 :global 才能生效，试了下还真是！赶紧去补了下这个关键字的知识，在这里做一个记录。

坑

　　在 React 项目中使用 scss/less，如果想让样式仅作用在某个组件，而不影响全局，一般都会把样式文件进行模块化，即打包后每个 class 名都会被自动加上一串唯一的序列号。

举个例子：

1
2
3

.main {
     width: 100px;
}

 
模块化后打包的结果会是：

1

.main__3D0Xe{ width: 100px; }

 
　　而我们公司的框架自动做了样式的模块化，因此正是这串序列号导致无法正确选中 antd 组件内部元素的 class🤣。

解决方法

　　如果不想要这串序列号，那么在最外层套上一层 :global 即可～

　　最近在做宝马的一个项目，需要实现 Table 的全选 & 取消全选，原型图如下:

　　然而，antd 官网给的例子里只有在组件中的实现方法（自定义选择项——通过 rowSelection.selections 配置），如下图:

　　如果想要做到原型图这样在组件外实现全选 & 取消全选，则需要更灵活地运用 rowSelection 这个配置项。

Talk is cheap, show me the code!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

const [selectedRowKeys, setSelectedRowKeys] = useState([]);
const [selectedRows, setSelectedRows] = useState([]);
const [tableData, setTableData] = useState([]);

useEffect(() => {
  setTableData(mock); // 将 tableData 先设为表格内的全部数据
}, []); 

// 关键点：这个函数既作为回调函数，也能手动调用～
const handleChange = (selectedRowKeys, selectedRows) => {
  setSelectedRowKeys([...selectedRowKeys]);
  setSelectedRows([...selectedRows]);
};

// 点击 选择全部 的回调函数
const selectAll = () => {
  tableData.forEach((o, i) => {
    // 遍历，和全部的 tableData 作对比，找到没有勾选的 row, 将它的 key 值保存到 selectedRowKeys 数组
    if (!selectedRows.includes(o)) selectedRowKeys.push(tableData[i].account);
  });
  // 手动修改 selectedRowKeys，和 Table 组件内的 selectedRowKeys 联动
  handleChange(selectedRowKeys, [...tableData]); 
};

// 点击 取消全部 的回调函数
const selectNone = () => {
  // 手动修改 selectedRowKeys 和 selectedRows，全部置为空
  handleChange([], []);
};

const rowSelection = {
  selectedRowKeys, // 受控
  type: "checkbox",
  onChange: handleChange // 将 handleChange 定义在外面，从而可以手动调用
};

// Table 组件，略去了无关配置
  <Table
    rowKey="account"
    columns={columns}
    dataSource={mock}
    rowSelection={rowSelection}
/>

总结

　　其实最关键的地方在于 rowSelection 里的 onChange ，通常的回调函数我们不会直接调用，而在这里，如果要实现在表格外全选，则需要手动调用这个 onChange 。

2023.1.21 更新

　　最近做了个需求，需要在一个 form 中做三个字段间的联动:

　　期间遇到了form.setFieldsValue 不会触发控件 onChange的问题，找到了一个解决方案，和我这篇文章的思路挺像的，也是需要手动触发一个回调函数，在这里更新记录一下。

TL;DR

线上支付的懒人包(工行版)：

• 前往就近的工行网点。
• 手机是无法支付的，带上电脑，下载好旧版的 IE 浏览器。
• 打消直接使用银联卡支付的念头，花 70 元购买 U 盾。
• 使用 U 盾前需要下载安全证书，如果页面上下载安全证书的链接点击后闪退，请工作人员在工行 app 上下载蓝牙安全证书。
• 使用 U 盾前需要下载安全控件，如果页面上的下载弹窗无法下载，前往工行网银官网，点击页面最下方网银助手的链接进行下载。
• 付款吧！

设备的坑

　　首先移动端的 app 是支付不了的，意味着手机无法操作，只能通过 PC 端付款；

　　然后，和上大的毕设管理网站一样，只能用老 IE 登录，Edge，Chrome 和火狐等现代浏览器都无法成功进入付款界面。

付款界面的坑

　　进入付款页面后可以直接忽略页面上的付款流程， 应该是 2015 年以前的版本没更新。2015 年 2 月 15 日之后银联卡有了 5 万元的单日/单笔支付限额，但沪牌价格要 9w+，根本不能直接付款。(和使用哪家银行的银行卡没有关系，三个付款选项除了分期付款，其他两个都是银联，就会存在 5 万的额度上限)

　　报错之后我去工行网点加了卡的额度，但还是会显示超额，心态第一次炸裂😑。

　　本来已经打算放弃线上支付了，工作人员让我试试 U 盾，没想到又是一条新的踩坑之路。

使用 U 盾的坑

　　花了 70 搞了个 U 盾，使用之前需要下载安全证书，但估计是 IE 的问题，安全证书的下载链接一点击就会闪退，刚开始尝试就遇到了阻塞性的 bug，心态第二次炸裂😑。

　　但又出现了转机，一个年轻小哥和我说工行 app 也能下载安全证书，经过他的操作，15 分钟后我拥有了一个蓝牙安全证书，从而能够继续尝试下去。

　　接下来跳出了一个弹窗，提示我安装一个安全控件，点了确定之后会出来一个另一个弹窗，此时不管你点重试还是取消选项都会自动退出网银登录，而每次重登都要输身份证手机号验证码，来回搞了七八次还是没有装成功，心态第三次炸裂😑。

　　我问工作人员官网能不能下这玩意，工作人员说好像可以，于是我上官网寻找，首先没有任何提示性的信息，其次在搜索框搜关键词也没有任何结果，找了大概有十几分钟才发现在他妈的页面最下面，这到底是哪个反人类的 UX 设计的，这么关键的东西是真的一点指引都没有啊！！

　　这个下完之后总算成功支付了，我安慰自己，不断折腾也是人生的意义😑。

End

　　拍牌已经够难的了，没想到付个款也能这么 disgusting🤣。

　　我第一时间就联想到了 12 年东决 G6 ，因为这两场比赛的结果都不只是停留在那一场或是那一轮系列赛，而是会影响一个巨星二三十年后的定义。

　　况且，两场比赛的主角名字里都带詹姆斯，也算是个奇妙的联结。

　　毋庸置疑的是勒布朗詹姆斯当时的处境比现在的詹姆斯哈登还要艰难的多，在 2010 年休赛期与韦德、波什组成三巨头后，那支热火成为了真正意义上的全民公敌：除了迈阿密的球迷，其余 29 队的球迷都希望热火一败涂地，希望詹姆斯终身无冠。

　　也真的如大家所愿，11 年总决赛，那支热火被老司机带着一群暮年球员击溃。随着诺维斯基彻底摆脱了软蛋的骂名，詹姆斯成为了全联盟的笑柄。

　　无法想象那个休赛季詹姆斯是如何承受漫天的质疑和嘲讽的，很明显，下个赛季如果再不夺冠，三巨头必将解散，詹姆斯将万劫不复。

　　2011-2012 赛季，热火东部第二，东决将对阵曾经多次淘汰詹姆斯的凯尔特人队。尽管热火先下两城，但却被老辣的绿军连扳三场，濒临淘汰。

　　G6，在绿军的死亡主场，漫天嘘声。

　　结局我们都知道，詹姆斯砍下 45+15+5，还有那个著名的死亡之瞳。热火将比赛拖入抢七并击败绿军，又势如破竹地在总决赛轻取年轻的雷霆，詹姆斯拿到了生涯第一个冠军戒指，从那时开始了逐神之路。

　　今天的 G6，火箭主场，全场助威。印象深刻的是一个球迷举的牌子: “The best gift for Mother’s Day is G7.”

　　但结果我们也知道了，在考辛斯和杜兰特伤退，库里受手指影响上半场 0 分的情况下，火箭仍然被击败，可能丧失了哈登核心时代最后的夺冠希望。

　　并非要黑哈登，只是这场 G6 和哈登前几年的季后赛表现很可能会被反复拿出来衡量哈登的历史地位。而且如果，我说如果，在今天如此天时地利人和的情况下火箭击败了勇士，那大概率很多事情就不一样了。就像詹姆斯如果输掉了 12 年的那场东决，那么也不会有如今坐二望一的评价了。

　　这场比赛很可能让哈登在命运的十字路口迈向了一条不那么美好的路。