十一点半。屏幕一暗，我整个人跟被抽了筋似的。白天那张表，连喝水都按半小时一个节点排满了。结果呢？全让一个临时拉会的消息、一条必须秒回的微信，或者干脆就是身体突然亮起的红灯给搅黄了。盯着桌上那张被划掉又重写的时间表，心里那股熟悉的焦躁劲儿又上来了：是不是我又没拿捏住？是不是计划表一断档，整个人生就得崩盘。说实话，这种“计划赶不上变化”的破事儿，搁谁身上不膈应？
手边搁着本《计算机原理教程实验指导》。书是前年淘的二手，封皮早卷了边，翻到这一页纸都快脆了。我顺手扒拉出“中断电路设计”那章。实验手册写得干巴巴，就几行字：怎么搭中断请求寄存器，咋写中断服务程序，主程序跑到半道儿怎么安全歇脚，接住外头的信号，再严丝合缝地切回原轨道。
搁以前，我总把这当成计算机应付突发状况的“权宜之计”。凑合用呗。现在咂摸过来，未必是妥协。倒更像是整套系统能一直转下去的命根子。
咱们平时总爱把自己活成一条死板的流水线。早上睁眼就掐表：七点看书，八点健身，九点准时开工。好像只要踩着这死节拍走，日子就能像瑞士表一样滴答精准。可生活这玩意儿？压根不按节拍器走。它更像一堆乱窜的杂信号，随时可能给你来个急刹车。娃半夜突然烧到39度。同事临下班突然甩来个“帮我过一下”。甚至走在街上，莫名其妙就emo了。碰到这些“中断”，咱们第一反应绝对是硬刚。总觉得手头的事儿不能断，死活想干完。结果呢？主线程直接卡死。脑子宕机。正事没推进，觉也没睡踏实。全耗在原地内耗。这事儿大概就是这么个意思——你越较劲，系统越容易蓝屏。
书里顺带提了个DMA，直接内存访问。这词儿听着挺硬核，说白了就一句话：遇上那种数据量大、耗时长的粗活，别死磕着让CPU一个个去搬砖。直接开个专用通道，扔后台跑。CPU顶多开头和结尾打个招呼。中间过程？它爱干嘛干嘛去。
读到这儿我愣了好半天。咱们太习惯把每个“中断”都攥在手心里亲力亲为了，总觉得事儿得自己盯着进度条，才算尽到本分。可人毕竟不是铁打的，缓存和主频都有上限。像修一段关系、一项技能的积累，或者单纯消化一股子坏情绪，这些事儿根本不适合用“中断服务”去硬顶。我觉得吧，与其死磕，不如给它们开个DMA后台通道。开头把资源拨好、边界划清楚，剩下的交给时间慢慢发酵。不用隔五分钟就去戳一下进度条，更别因为暂时没见着动静，就焦虑地重启系统。不过话说回来，这招也不是万能的，有些紧急事儿还真不能甩后台，该接还得接。
说实在的，我以前特反感这种“挂后台”的状态。总觉得事儿悬在半空，心里发虚，跟欠了钱似的。后来才咂摸出那股发虚的劲儿，其实是怕失控。怕计划脱轨，怕自己跑偏了路线。但那个电路实验还教了我一招：调bug本来就是写代码的题中之义。哪有一上来就能完美跑通所有指令的初版CPU？改线、重跑测试序列，这些破事儿不是系统要完蛋的证据，而是它慢慢稳当起来的必经过程。
过日子大概也一个理儿。那些被打乱的安排、那些没按剧本走的人际关系、那些突然拐弯的念头，都不是人生系统出bug了。它们只是系统在设计之初，就该预留好的中断向量表。咱们不用费劲去消灭它们，得学会怎么配。啥时候该接招，啥时候该排队，啥时候干脆扔后台，啥时候直接无视。这本事课本上印不出来，只能在一遍遍的运行和报错里，自己拿脚蹚出来。不过我也得坦白，有时候“扔后台”纯属自我安慰，真遇到要命的坎儿，该死磕还得死磕。
窗外的马路早静了，连辆出租车都看不见。我重新敲开电脑，没急着去补白天的窟窿，也没把明儿的行程表塞满。只是把那个一直悬在嗓子眼的念头，轻轻推到了后台。
人这一辈子，本来就没法把每条指令都编排得滴水不漏。能在某个晚上，允许自己暂时不响应所有的中断，就安安静静发会儿呆，已经挺不错了。明儿太阳一出来，时钟周期照样滴答走。那些还没处理完的请求，就扔给明天的自己，或者交给时间慢慢跑吧。当然，要是明天一睁眼还是乱成一锅粥，也别太往心里去。系统重启一下，总能接着转。