小年夜里窗外偶尔有零星的鞭炮声，我坐在电脑前把最后一个依赖装完，看着终端里的构建信息一路跑绿，突然觉得“代码不止，温暖不息”这句话特别应景。代码这东西，平时是饭碗、是工具、是解决问题的武器，但到了小年这种节点，它更像一种陪伴——陪我把手头没做完的事收尾，陪我折腾一点让自己开心的玩具，也陪我在节前整理好环境、填好坑，好让来年开工的时候不手忙脚乱。
这篇文章不打算写成标准教程，更像是小年夜的一次代码笔记汇总。我会从这些年夜常碰到的实际场景出发，把开发环境整理、经典代码回顾、有点温度的趣味项目、进阶复现思路、还有那些让人头疼的编译与环境问题，通通过一遍。想看字体配置的可以直接跳到第一章，想找爱心代码的去第三章，被编译报错折磨的直奔第五章。每段我都会把思路和踩坑过程写清楚，尽量做到既能当消遣读，也能在年后直接照着操作。
1. 小年夜还在敲代码的人，先收拾一下这套环境
1.1 WSL下最接近macOS体验的字体配置
如果你跟我一样，工作机是Windows，但平时又喜欢在WSL Ubuntu里写代码，大概率会纠结一个问题：明明终端里都是等宽字体，为什么看别人的macOS终端截图那么舒服，自己这里总觉得字太挤、中文注释和英文对不上行？
问题多半出在字体渲染和字体选择上。macOS的终端默认用SF Mono或者Menlo，这两款字体的中宫比较大，字符间距均匀，看久了不累。Windows Terminal里想接近这个体验，我试了一圈下来，最稳妥的组合是Cascadia Code配一个中文字体回退。Cascadia Code是微软自家的等宽字体，和SF Mono的气质比较接近，而且对连字（ligature）支持得不错。如果你不喜欢连字效果，用Cascadia Mono也行。
关键一步是设置字体回退。在Windows Terminal的配置文件settings.json里，把profiles -> defaults -> font -> face 改成这样：
{ "profiles": { "defaults": { "font": { "face": "Cascadia Code", "size": 12 } } } }但这只能保证英文和代码符号的显示。中文注释部分，如果系统找不到匹配字体，Windows Terminal会自动落到微软雅黑或者宋体，这时候中英文混排就容易对不齐、显得乱。我的做法是装一款更纱黑体（Sarasa Term SC），它是一款把英文等宽和中文黑体做了对齐优化的字体，特别适合写代码时中英文混排的场景。装完之后把字体改成“Sarasa Term SC”，你会明显感觉整段代码的节奏对了，尤其是行尾分号和中文注释对齐的时候，那种舒适感非常接近macOS。
如果你还觉得差点意思，可以把光标样式从竖线改成实心方块（也就是所谓的“块状光标”），再把行距稍微调大一点，视觉上会更松弛。这个改动虽然小，但配着新字体一起用，观感提升不少。
1.2 VSCode写C没有代码提示，从这三步查起
VSCode + C/C++扩展写C语言，按理说开箱就能有补全和跳转，但很多人实际用下来会发现：函数名不提示、结构体成员点不出来、头文件里的宏定义半天不生效。小年夜这种时候本来想安安静静写点代码，结果被补全问题一搞，心态直接崩。我排查过不少次这种问题，原因基本集中在三个地方。
第一步，看C/C++扩展装没装对。现在VSCode的C/C++扩展有个奇怪的现象：插件市场里有好几个同名或相似的扩展，不小心会装到社区维护的旧版本。正版是Microsoft官方那个C/C++，装完之后右下角或者命令面板里能看到“C/C++: Log Diagnostics”这个命令。如果这个命令都没有，多半是装错了。
第二步，看IntelliSense Engine。打开设置，搜“C_Cpp.intelliSenseEngine”，推荐选“default”。有些旧教程会让你选“Tag Parser”，那是老黄历了，现在默认引擎对C++17和C11的支持更好，而且能读compile_commands.json。如果你发现补全偶尔有但很慢，可以把“C_Cpp.intelliSenseCacheSize”调大一点。
第三步，也是八成问题的根源：includePath配置不对。尤其是用MinGW或者WSL工具链的时候，VSCode默认的includePath里没有编译器自带的头文件路径，导致stdio.h、stdlib.h这些基础头文件都扫不到。解决办法是在c_cpp_properties.json里把编译器路径指定好：
{ "configurations": [ { "name": "Win64", "includePath": [ "${workspaceFolder}/**", "C:/Program Files/mingw64/include/**" ], "compilerPath": "C:/Program Files/mingw64/bin/gcc.exe", "cStandard": "c17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }配置完重启一下VSCode，你会发现之前飘红波浪线的include一下子好了。如果还在用WSL，那就在WSL窗口里装好Remote WSL扩展，然后直接用code命令打开目录，C/C++扩展会自动调用WSL里的gcc。
1.3 把代码推到Gitee仓库，细节别忽略
节前把一年的代码整理好推到远程仓库，是很多人的习惯动作。Gitee在国内的访问速度比GitHub稳，私有仓库也不收费，所以用它来存代码很常见。但“上传代码到仓库”这件事，看着简单，实际坑不少。
首先，如果你在Gitee上新建了一个仓库，而本地已经有一个老项目，最直接的做法是：
git init git add . git commit -m "init" git remote add origin https://gitee.com/你的用户名/你的仓库名.git git push -u origin master但这里有个容易卡住的地方——如果远程仓库在创建时勾选了“初始化仓库”，里面会有一个README或者.gitignore，本地直接push会被拒绝，提示远程包含本地不存在的提交。解决办法是先拉取再合并：
git pull --rebase origin master git push -u origin master另外，从2022年开始Gitee就不再支持账号密码直接push了，push的时候需要输入用户名和个人访问令牌。个人访问令牌在Gitee的“设置 -> 安全设置 -> 私人令牌”里生成，生成的时候勾选projects权限就行。很多人第一次被卡在这里，以为是密码错了，其实是没搞清楚令牌这回事。
如果你有多个账号或者经常换电脑，建议配好SSH key：
ssh-keygen -t ed25519 -C "你的邮箱" cat ~/.ssh/id_ed25519.pub然后把公钥加到Gitee的SSH公钥列表，之后把remote地址改成git@gitee.com:你的用户名/你的仓库名.git就行。用SSH的好处是以后push不用再输密码，而且网络稳定性普遍比HTTPS好。我自己的习惯是：工作代码用HTTPS（方便临时别人借用），私人项目一律切SSH。
2. 经典算法与文件读写，是这时候最解压的代码
2.1 快速排序的两种写法，边界条件要记牢
过年期间写算法题有种莫名的仪式感，尤其是快速排序这种“面试必问、平时总忘”的经典。很多人一提到快排就紧张，其实它代码量不大，难的是边界条件。我习惯把快排拆成两种写法来记。
第一种是Lomuto分区法，思路最直白：选最后一个元素当pivot，用i标记“小于等于pivot的区域边界”，遍历整个数组，遇到小于等于pivot的就交换到前面来。代码是这样：
def quicksort_lomuto(arr, low, high): if low >= high: return pivot = arr[high] i = low - 1 for j in range(low, high): if arr[j] <= pivot: i += 1 arr[i], arr[j] = arr[j], arr[i] arr[i + 1], arr[high] = arr[high], arr[i + 1] pos = i + 1 quicksort_lomuto(arr, low, pos - 1) quicksort_lomuto(arr, pos + 1, high)这种写法好理解，但有个缺点：如果数组里重复元素很多，性能会退化。第二种Hoare分区法更接近教科书，它用两个指针从两端向中间逼近，遇到左边大于等于pivot和右边小于等于pivot的情况就交换，最后返回一个分界点。相比之下，Hoare分区的交换次数更少，实际运行更快，但递归参数的边界要特别小心：
def quicksort_hoare(arr, low, high): if low >= high: return pivot = arr[(low + high) // 2] i, j = low - 1, high + 1 while True: i += 1 while arr[i] < pivot: i += 1 j -= 1 while arr[j] > pivot: j -= 1 if i >= j: break arr[i], arr[j] = arr[j], arr[i] quicksort_hoare(arr, low, j) quicksort_hoare(arr, j + 1, high)注意Hoare写法递归调用的时候是(low, j)和(j + 1, high)，不是(low, pos - 1)和(pos + 1, high)。这个区别我踩过不止一次，写错就会无限递归或者丢元素。如果你想拿快排练手，建议直接把Python的递归深度改大一点再测大数据量：sys.setrecursionlimit(1000000)，不然一万个元素就可能触发递归上限报错。
2.2 C语言文件读写操作的完整示例
C语言的文件读写是很多自学者卡壳的地方，因为涉及指针、缓冲区、错误处理，一不小心就踩坑。小年夜想写个小工具把一些文本整理一下，用C语言做文件处理其实很顺手。
最基础的一套流程是：fopen打开文件，判断是否成功，然后fgets或fread读内容，fprintf或fwrite写内容，最后fclose关闭。
我给你一个比较完整的示例，功能是读取一个文本文件，在每行前面加上行号，然后写入新文件：
#include <stdio.h> #include <stdlib.h> #include <string.h> #define MAX_LINE 1024 int main() { FILE *in = fopen("input.txt", "r"); if (in == NULL) { perror("打开输入文件失败"); return 1; } FILE *out = fopen("output.txt", "w"); if (out == NULL) { perror("打开输出文件失败"); fclose(in); return 1; } char line[MAX_LINE]; int line_num = 1; while (fgets(line, sizeof(line), in) != NULL) { fprintf(out, "%d: %s", line_num++, line); } fclose(in); fclose(out); return 0; }这里面有两个细节值得注意。第一，fgets会连换行符一起读进来，所以fprintf里我用了"%d: %s"而不是"%d: %s\n"，否则每行之间会多一个空行。第二，fgets的第二个参数是缓冲区大小，不是“读多少字节”，它最多读size-1个字符，并在末尾补\0，这是防止缓冲区溢出的关键。
如果你处理的是二进制文件，比如图片或者自定义格式数据，那就不能用fgets读行了，应该用fread和fwrite：
FILE *in = fopen("input.bin", "rb"); FILE *out = fopen("output.bin", "wb"); unsigned char buf[4096]; size_t n; while ((n = fread(buf, 1, sizeof(buf), in)) > 0) { fwrite(buf, 1, n, out); }注意模式字符串里加了一个b，在Linux下加不加都行，但在Windows下不加会出大问题——文本模式会把\n转成\r\n，读二进制文件时数据就被破坏了。
还有一个高频问题：fopen路径里的反斜杠。在C语言的字符串里，"C:\Users\test\file.txt"里面的\U、\t都会被转义，路径根本打不开。要么用双反斜杠"C:\\Users\\test\\file.txt"，要么用正斜杠"C:/Users/test/file.txt"，Windows API是接受正斜杠的。很多人的代码在老师机器上能跑，回家就不行，十有八九是这个问题。
2.3 C#连续编号不重复的生成思路
有人问过一个很实际的问题：C#里怎么设计连续编号不重复？这个问题表面看是“生成一个数字”，实际上牵涉到并发、持久化、恢复场景，现实中很容易踩坑。
最简单的做法是用数据库自增ID，但有时候程序只是本地小工具，不想引入数据库。这时候常见方案是用原子操作，在单进程内用Interlocked：
private static int _currentNumber = 0; public static int GetNextNumber() { return Interlocked.Increment(ref _currentNumber); }这个方案在单进程、单应用内可以保证不重复，因为Interlocked.Increment是CPU级别的原子操作。但如果你想做的是像订单号这种，跨进程也不能重复，那就得换个思路。
比较常见的做法是“时间戳+随机数+序号”的组合，或者干脆用雪花算法（Snowflake）的核心思想。雪花算法的本质是：用一个64位整数，高位放时间戳，中间放机器ID，低位放同一毫秒内的序列号。用C#实现一个极简版大概是这样：
public class IdGenerator { private long _lastTimestamp = -1L; private int _sequence = 0; private readonly object _lock = new object(); public long NextId() { lock (_lock) { var timestamp = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(); if (timestamp == _lastTimestamp) { _sequence = (_sequence + 1) & 0xFFF; if (_sequence == 0) { while (timestamp <= _lastTimestamp) timestamp = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(); } } else { _sequence = 0; } _lastTimestamp = timestamp; return (timestamp << 22) | (0 << 12) | _sequence; } } }这里用了lock保证线程安全，timestamp << 22给时间戳留了高位空间，中间的机器ID先用0占位，低12位是序列号。这个思路学明白之后，不管以后是订单号还是流水号，你都能根据业务定制。聊这个不是为了让你背代码，而是想说明一个道理：所谓“不重复编号”，关键不在于随机数多复杂，而在于你如何保证并发生成时的唯一性和单调性。
3. 用几段带温度的代码，给小年夜加点仪式感
3.1 Python爱心代码，从小黑窗到动态图画
一到节日，各种爱心代码就成了程序员之间默契的“电子贺卡”。Python写爱心有几种不同层次——最基础的是控制台ASCII字符拼爱心，稍微进阶一点是用matplotlib画心形曲线，再进阶就是动态粒子效果。
先看最简单那种，直接用字符拼：
for y in range(15, -15, -1): line = "" for x in range(-30, 30): if ((x * 0.04) ** 2 + (y * 0.1) ** 2 - 1) ** 3 - (x * 0.04) ** 2 * (y * 0.1) ** 3 <= 0: line += "*" else: line += " " print(line)这是用笛卡尔心形方程(x^2 + y^2 - 1)^3 - x^2 * y^3 = 0来逐点判断要不要画星号。在小黑窗里跑起来，会有一颗由星号组成的爱心。如果你嫌字符太单调，可以把它改成turtle画动态爱心：
import turtle t = turtle.Turtle() t.color("red") t.begin_fill() t.left(50) t.forward(133) t.circle(50, 200) t.right(140) t.circle(50, 200) t.forward(133) t.end_fill() turtle.done()这段代码的原理是：用圆弧模拟爱心的两个半圆顶部，直线模拟下方的尖角。turtle.circle(50, 200)的意思是画半径为50的圆弧，扫过200度，两个圆弧对称一下正好凑成心形轮廓。
如果配上matplotlib还能做渐变效果，把心形区域内每个点都随机撒上不同透明度的红色点，看起来就像一颗发光的心脏。这些代码都不复杂，主要是好玩，适合小年夜发给朋友当彩蛋。
3.2 安卓点击文字特效的轻量实现
在小年夜这种场景下，给App加点节日氛围是件很有幸福感的事。安卓的“点击文字特效”是一个特别好的切入点——平常看起来普通的TextView，点击之后能缩放、变色、散开，会让人觉得整个界面活了起来。
最轻量的实现方式是给文字设置一个点击触摸反馈，重写onTouchEvent或者直接给TextView设置setOnTouchListener。我常用的一个方案是用ViewPropertyAnimator做缩放动画：
textView.setOnTouchListener((v, event) -> { switch (event.getAction()) { case MotionEvent.ACTION_DOWN: v.animate().scaleX(0.8f).scaleY(0.8f).setDuration(100).start(); break; case MotionEvent.ACTION_UP: v.animate().scaleX(1.0f).scaleY(1.0f).setDuration(150).start(); break; } return true; });这个效果是“按下去缩小、松开回弹”，很多按钮的按压反馈都是这么做的。如果你想更炫一点，比如点击字体会有一个光晕或者粒子炸开的效果，可以加入一个ObjectAnimator组合动画，同时驱动scale和alpha：
ObjectAnimator scaleX = ObjectAnimator.ofFloat(textView, "scaleX", 1.0f, 1.3f, 1.0f); ObjectAnimator scaleY = ObjectAnimator.ofFloat(textView, "scaleY", 1.0f, 1.3f, 1.0f); ObjectAnimator alpha = ObjectAnimator.ofFloat(textView, "alpha", 1.0f, 0.3f, 1.0f); AnimatorSet set = new AnimatorSet(); set.playTogether(scaleX, scaleY, alpha); set.setDuration(300); set.start();注意这里alpha最后也回到了1.0f，保证动画结束后文字完全可见。如果你把alpha的终点改成0，那字就消失了，适合做“点击文字消失”的彩蛋。
3.3 用CMD给电脑做一次节前体检
小年夜很多人会把电脑彻底清理一遍，硬盘健康检查是节前必做的项目。有不少人搜“扫盘代码cmd”，其实就是想知道不装第三方软件的情况下，怎么用CMD快速检测磁盘。
最常用的三条命令：
chkdsk C: /f这条负责扫描磁盘错误并尝试修复，需要管理员权限。如果C盘正在使用，它会提示是否计划在下一次重启时检查，输入Y确认就行。注意，/f是修复错误，如果你只想检查不想修复，去掉/f参数。
wmic diskdrive get status这条直接返回硬盘健康状态，输出OK就代表正常。它调用的是Windows Management Instrumentation，可以看成是一条精简版的健康检查命令。
sfc /scannow这条不是扫硬盘坏道，而是检查系统核心文件完整性，如果发现有文件损坏，会自动用系统缓存里的副本替换。我遇到过好几次节前排查电脑卡顿，跑完这条之后系统明显稳定下来的情况。
如果你想看更详细的S.M.A.R.T.数据，CMD还是有点局限，建议用专业的CrystalDiskInfo。但日常“有没有坏道、系统文件坏没坏”这些，上面三条命令已经够用了。顺手说一句，chkdsk扫描大容量机械硬盘的时候会很慢，别中途强制关窗口，容易造成文件系统二次损伤。
4. 从复现到自研，进阶代码的正确打开方式
4.1 多模态模型复现的拆解步骤
小年夜刷到ControlNet、多模态大模型相关的代码，很多人会忍不住想复现一遍。但说实话，直接拉一个仓库下来跑，十个有九个会卡在环境依赖上。我复现多模态模型的思路是先拆步骤，再逐项打勾。
多模态模型，比如CLIP、BLIP这类，核心逻辑其实可以拆成三块：视觉编码器提取图像特征、文本编码器提取文本特征、对比学习损失把匹配的图像-文本对拉近。如果你只是想从零复现一个简化版，千万别一上来就用完整数据和大batch，那个显存要求直接劝退。
我建议按这样的路径走：第一步，准备一个小数据集，几百对图文就够了，目标不是训练出好效果，而是跑通流程。第二步，用预训练好的image encoder和text encoder，冻结它们，只训练一个映射层，这样可以大幅降低训练成本。第三步，把batch size设成8或者16，用混合精度训练，损失函数用InfoNCE，可以写成下面这个简化版：
import torch import torch.nn.functional as F def contrastive_loss(image_embeds, text_embeds, temperature=0.07): logits = torch.matmul(image_embeds, text_embeds.T) / temperature labels = torch.arange(logits.shape[0], device=logits.device) loss_i = F.cross_entropy(logits, labels) loss_t = F.cross_entropy(logits.T, labels) return (loss_i + loss_t) / 2复现的时候最容易被忽略的是预处理。图像缩放中心裁剪的尺寸、文本tokenizer的最大长度、归一化的均值方差，这些如果跟原版不一致，哪怕代码逻辑完全相同，训练效果也会天差地别。我有一回就是因为图像resize的插值方式和原版不一样，损失怎么都下不去，后来对着原仓库的dataloader逐行比对才找到。
4.2 TD3强化学习代码的PyTorch实现要点
如果你对强化学习感兴趣，TD3是很值得从零复现的算法。TD3全称Twin Delayed Deep Deterministic policy gradient，它的核心价值在于解决了DDPG容易过估计Q值的问题。复现TD3，关键要理解它的三个trick：双Q网络取最小值、目标策略平滑、策略更新延迟。
双Q网络，就是说Q网络有两个，计算目标Q值的时候取两个网络给出的较小值，这能抑制过估计。目标策略平滑，是给目标动作加一点噪声，让Q值对动作的估计更平滑。策略更新延迟，是让Actor网络每两步或者更多步才和Critic同步更新一次，因为Critic先稳定了Actor才能学到更好的策略。
PyTorch实现时，Critic网络结构大概长这样：
class Critic(nn.Module): def __init__(self, state_dim, action_dim): super().__init__() self.fc1 = nn.Linear(state_dim + action_dim, 256) self.fc2 = nn.Linear(256, 256) self.fc3 = nn.Linear(256, 1) def forward(self, state, action): x = torch.cat([state, action], dim=1) x = F.relu(self.fc1(x)) x = F.relu(self.fc2(x)) return self.fc3(x)注意这里是两个独立的Critic网络，所以通常会写两个这个类，或者用一个类实例化两个对象。更新目标Q值时，要复制两份目标网络，用target_critic_1和target_critic_2分别输出，再取最小值。
复现TD3最大的坑不是网络结构，而是超参数和随机种子。原论文用的是2e-4的学习率、100万步的经验池、batch size 256、动作噪声是零均值高斯噪声标准差0.1。这些参数看着平淡，但改一个效果就差很远。我还建议你在不同随机种子下跑多个实验取平均，因为单次种子起伏很大，很容易得出错误结论。
AI抢走写代码工作是个不断被提起的话头，但我想说的是，恰恰是这些从零复现的过程，才让人真正理解了模型、理解了框架。工具会更迭，但底层原理不会，这就是“代码不止”的另一层意思。
4.3 LoRa通信与I2C EEPROM的嵌入式代码配合
嵌入式方向的朋友，小年夜可能还在捣鼓物联网板子。LoRa通信和I2C EEPROM是两类很典型的需求，代码层面有不少细节值得记录。
LoRa模块，比如SX1278，是通过SPI接口和MCU通信的。初始化的时候要设置频率、带宽、扩频因子、编码率，发射的时候要把数据写进FIFO，再触发发送指令。一个最简的发送流程是：
void lora_send(uint8_t *data, uint8_t len) { lora_set_mode(STANDBY); lora_write_buf(REG_FIFO, data, len); lora_write_reg(REG_FIFO_ADDR_PTR, 0); lora_write_reg(REG_OP_MODE, MODE_TX); // 等待发送完成中断 while ((lora_read_reg(REG_IRQ_FLAGS) & IRQ_TX_DONE) == 0); lora_write_reg(REG_IRQ_FLAGS, IRQ_TX_DONE); }这里要注意FIFO地址指针必须在写数据之前重置为0，否则数据位置会乱。还有，读IRQ_FLAGS之后必须手动把中断标志位清零，不然下一次发送会误判。
I2C读写EEPROM（比如AT24C02）则是另一个常见需求。Verilog实现I2C控制器的核心，是状态机切分和ACK/NACK时序处理。EEPROM的写操作是先发送设备地址，再发送存储地址，最后发送数据。读操作更麻烦一点，要先发一个伪写命令把存储地址指过去，然后重新发送起始条件和读方向设备地址。
写Verilog的时候最容易出错的地方是SDA在SCL高电平期间的变化。I2C协议规定，SDA只能在SCL低电平期间变化，高电平期间必须保持稳定。很多人不懂这个，代码里SDA任意时刻都变，导致仿真波形看起来对，上板就死。我记得一个很常见的测试是：先单字节写，再读回来比对，能通过这个测试基本就说明时序对了。
5. 小年夜最容易踩的编译与环境坑，我替你们先踩了
5.1 VS2010编译报错MSB6006的全链路排查
有些人还在维护老项目，小年夜想趁假期把旧代码重新编译一下，结果VS2010直接甩出一个error MSB6006: "cmd.exe" exited with code 3。这个报错最坑的地方在于，它只告诉你cmd.exe退出码是3，完全不说是哪一步出了问题。
我排查这个问题时的链路是这样的。第一步，把输出窗口切到“工具 -> 选项 -> 项目和解决方案 -> 生成并运行 -> MSBuild项目生成输出详细程度”，改为“详细”或者“正常”。重新编译，这时候输出里能看到具体是哪个命令行工具执行失败了。
第二步，如果是资源编译器或者自定义生成事件失败，九成是因为路径里有空格。VS2010比新版本更脆弱，很多配置项不会自动给路径加引号，如果项目放在C:\Users\My Projects\demo这种带空格的路径下，cmd.exe解析命令时就会出错。解决办法是把项目移到纯英文无空格路径，比如D:\projects\demo。
第三步，检查有没有缺少系统环境变量。VS2010在编译时依赖VCInstallDir和FrameworkSDKDir这些环境变量，如果之前装过其他版本的Visual Studio，或者环境变量被清理过，命令行工具找不到依赖库，就会通过非零退出码结束。可以在CMD里执行echo %VCInstallDir%确认变量有没有值，没有的话需要用vcvarsall.bat重新初始化环境。
如果这些都没问题，那就要看是不是杀毒软件拦截了cmd.exe。老版本VS的编译进程经常被杀毒软件误伤，临时关闭实时防护再编译一次就能定位。说实话，VS2010现在基本属于“博物馆藏品”级别，如果业务允许，我强烈建议至少升到VS2015或2019，光是编译器对C++11的支持就能让你少掉不少头发。
5.2 Windows设备管理器报代码31，别急着重装
这块算是经典问题了。设备管理器里某个硬件上面有个黄色感叹号，属性里写着“由于 Windows 无法加载这个设备所需的驱动程序，导致这个设备工作异常。 (代码 31)”。
很多人一看代码31就以为是驱动坏了，直接去官网下驱动重装。但根据我的经验，代码31的情况分两种：一种是驱动文件确实坏了，另一种是驱动在注册表里的记录和实际文件对不上。后者占的比例其实很高，尤其是Windows更新之后。
第一种情况的处理比较常规：卸载设备，勾选“删除此设备的驱动程序软件”，然后重新扫描硬件改动，再安装一次驱动。第二种情况，我建议先用管理员CMD执行一下：
pnputil /enum-drivers这个命令能列出所有第三方驱动包，你可以看看那个出问题的设备对应的驱动是否还在系统里。如果驱动文件已经被删掉但注册表里还有残留，Windows就会认为驱动存在，但实际加载不了，于是给出代码31。这时候可以手动清理注册表：
reg query HKLM\SYSTEM\CurrentControlSet\Enum /s /f "你的设备名"但改注册表有风险，操作前记得先导出备份。更稳妥的办法是下载驱动安装包右键“安装”，强制让系统重建驱动信息，很多时候跑一遍安装包就能把对应关系修好。
如果遇到的是通用总线设备，比如USB控制器代码31，还可以试试把BIOS里的Legacy USB Support关掉再打开，让硬件重新枚举一次。这种玄学操作其实背后的原理是清掉主板的设备缓存，有时候真的有效。
5.3 SHA-2代码签名补丁，发布工具的必要一课
现在做Windows软件开发，代码签名几乎绕不开。尤其是要在新系统上分发exe，如果签名算法还是SHA-1，Windows 10以上的SmartScreen会直接弹警告，甚至某些安全软件直接报毒拦掉。
SHA-2签名补丁这件事，主要影响的是老系统环境。Windows 7 SP1和Windows Server 2008 R2默认只信任SHA-1签名，如果要在这类系统上运行SHA-2签名的程序，需要安装微软的补丁KB4474419和KB4490628。这俩补丁一个负责更新签名验证逻辑，一个负责更新根证书列表。很多老软件在新系统上报“未签名”。其实是签名链上某个环节没有升级。
用signtool给exe签名，最常用的是SHA-256格式：
signtool sign /fd SHA256 /a /tr http://timestamp.digicert.com /td SHA256 /v MyApp.exe这里面的参数分别表示：/fd指定文件摘要算法为SHA256，/a自动选择有效的签名证书，/tr指定RFC3161时间戳服务器，/td指定时间戳摘要算法也是SHA256，/v显示详细信息。加上时间戳很重要，这样即使证书过期，已经签名的程序仍然会被系统认为签名有效。
我在实践中的体会是，SHA-2不只是一个“算法升级”，它更提醒我们：发布工具这件事，要和系统生态同步。如果你维护的老项目一直没更新签名配置，趁着节前整理代码库的时候顺手把签名流程升级一下，来年发布就不会被安全策略卡脖子。
小年夜的代码写到这儿，窗外已经彻底安静了。说回开头那句“代码不止，温暖不息”，我突然想到，真正让代码有温度的，其实不是它本身，而是写代码的人愿意在烟火气里坐下来，为一个报错翻文档，为一个特效反复调参，为一个老系统多兼容一个补丁。这些看似细碎的坚持，才是技术人最好的年味。来年开工，愿你的代码永远跑得通，愿你的温暖永远有人收得到。
