代码优雅之道：50个提升可读性与质量的实用技巧

“代码优雅”这四个字，你刚入行那阵可能会觉得虚，但等你接手过一个写满 a、b、tmp 的旧项目，或者在别人五百行的 longMethod 里翻过半天 bug，你就明白它有多重要了。代码表面上是写给机器执行的，实际上真正的读者是看代码的人，包括三个月后的你自己。这篇文章整理了 50 个让代码更优雅的小技巧，覆盖命名、函数、条件、错误处理、数据结构、性能、注释和工具链，基本都是动手写代码时能直接落地的习惯。适合刚工作的新人，也适合写了好几年代码、想回头收拾自己烂摊子的老手。不用一次性全记住，挑几条放进自己的代码里，效果马上就能看到。

1. 命名：代码的第一张脸，也是最低成本的优化

命名是投入产出比最高的代码改进方式。你不需要懂任何高深理论，只需要在每次给变量、函数、类起名字的时候多花十秒钟想一下，后面节省的时间按小时算。我见过太多代码变量叫 a、bb、tmp，函数叫 doIt、handleThing，写的时候很爽，两周后回来看，谁都不认识。命名的核心只有一条：让读到名字的人不看上下文就知道它在说什么。

1.1 变量命名：让名字自己说话

变量名是代码里出现频率最高的东西，也最容易被敷衍。很多新手觉得变量名随便起无所谓，反正值才是关键。这是最大的错觉。变量名的好坏，直接决定这段代码能不能被快速理解。这里的“别人”，很大程度上就是两周后的你自己。

01. 变量名写业务含义，不要写缩写和类型。
比如一组学生年龄，不要叫 l、list1、intArr，直接叫 student_ages。单个字母 l 和数字 1 还容易混淆，写的时候顺手，看的时候就想骂人。另一个例子是存用户名的字段，不要写 un，写 username；存邮箱的不要写 em，写 email_address。

python复制# 不好
l = [18, 20, 22]
# 好
student_ages = [18, 20, 22]

02. 布尔变量用 is/has/can 这类前缀开头。
布尔值是代码里语义最轻、也最容易被误解的变量。is_active、has_permission、can_edit，一眼就知道这是条件判断。不要写 flag = True，这个 flag 到底表示什么？没人知道。也不要写 status = 1 这种数字状态码，一个 status 带上一个魔法数字 1，读代码的人还得去查枚举定义。

python复制# 不好
flag = True
# 好
is_active = True
can_edit = False

03. 缩写要克制。
id、url、http 这种通用的缩写可以用，但 usrNm、cfg、pwd 这种随意缩的要避免。代码不是加密文，没必要为了省几个字符增加阅读成本。比如 password 就写 password，config 就写 config，清晰比短重要得多。我唯一允许短缩写的场景，是 for 循环里的循环变量 i、j、k，它们的作用域只有三五行，不会造成理解负担。

04. 不用 data、info、temp 这类万能模糊词。
data 到底是什么数据？info 是哪方面的信息？temp 为什么存在？这类名字等于把理解成本全部甩给读者。除非在写非常临时的代码，否则尽量避免。我一般允许 tmp 只出现在三行以内的交换变量场景里，再长就不行了。如果你发现自己在变量名里写 data2、final_data、data_final，说明这个变量的职责还没理清。

注意：命名这件事，不要为了“看起来短”牺牲“读起来懂”。该长就用完整单词，比如 password 不要写成 pwd，除非这是整个项目的统一约定。

1.2 函数与类的命名：动词宾语是个通用公式

函数和类名比变量级别更高，因为粒度更大，一旦乱了，代码骨架就歪了。函数命名建议遵循一条公式：动词加宾语，让人一看就知道这个函数做了什么事。我最怕看到 handle、process、do 这种万能动词，它们基本等于“我也说不清自己在干嘛”。

05. 函数名用动词开头的动宾结构。
get_user_by_id、update_avatar、send_notification，都比 handle_user、do_thing 清楚得多。动词也要准确，get 表示查询，update 表示修改，send 表示发送。用词准确了，函数内部做什么，调用方基本能猜到一半。

python复制# 不好
def handle(user):
    ...

# 好
def get_user_by_id(user_id):
    ...

06. 类名用名词，接口名用能力词。
UserRepository、PaymentService 是名词，表示一类对象；EmailSender 是能力，表示它能发邮件。别把类名起成动词，比如 Login 不是一个类，LoginSession 才是。接口名同理，尽量用一个能表示能力的名词或形容词，让读者一看就知道实现方承诺了什么行为。

07. 多用业务领域的词汇，让代码靠近需求文档。
业务里叫“逾期”，代码变量就叫 is_overdue，不要写 check_day_gt_today。前者读一遍就懂，后者还得算一下今天是不是大于到期日。代码和需求用同一套词汇，跟产品经理沟通的时候也会顺畅很多。这个习惯在业务系统里价值极高，因为大部分代码就是在翻译业务规则。

08. 一致性比某一次选得更“高级”更重要。
团队里如果有人用 get，你就跟着用 get，不要再用 fetch、retrieve 混着来。统一词汇表的价值，在于整个代码库形成一种可预测的节奏，读起来顺滑。这个优先级，高于“我觉得这个英文单词更准确”。代码评审时，与其争论哪个词最好，不如定个原则：核心动词列表写进团队规范，其他人照着用。

1.3 常量与魔法数字：把“数字天书”变回人话

代码里最让人头秃的东西之一就是魔法数字。一排 if retry > 5，这个 5 是哪来的？为什么是 5？写成具名常量之后，含义一目了然，以后调整阈值也只需要改一个地方。

09. 常量用全大写加下划线，消灭魔法数字。
比如 MAX_CONNECTION_RETRIES = 5，用的时候写 if retry_count > MAX_CONNECTION_RETRIES。这样做的好处不光是可读，还避免了“改了这处漏了那处”的隐患。像下拉刷新时间、超时时间、密码长度限制，这些都应该是常量，不应该散落在代码各处。

python复制# 不好
if retry_count > 5:
    ...

# 好
MAX_CONNECTION_RETRIES = 5
if retry_count > MAX_CONNECTION_RETRIES:
    ...

10. 命名的可搜索性要够，长度适中。
太短的名字如 MAX_R、CNT，搜出来一堆无关结果；太长的名字如 maximum_number_of_connections_to_database 又笨重。要选那种既不撞词、又能让人一眼看懂的长度。一个衡量标准：在 IDE 里全局搜索这个常量，结果应该都是有效引用，而不是误伤一片。如果是 Java 里常见的 static final 常量，还可以配合类名提供上下文，比如 DbConstants.MAX_POOL_SIZE。

2. 函数设计：把一个大故事拆成一堆小卡片

函数是代码组织的基本单元，写得好不好直接决定这堆代码是“看得懂”还是“看不懂”。我见过最多的坏味道就是长函数：一个函数几百行，前半段解析参数，中间处理业务，最后拼 SQL，逻辑像毛线团。好的函数像一张小卡片，名字就是卡片标题，看标题就知道内容，内容短到不用翻滚动条。

2.1 单一职责与“一眼清楚”的函数体

为什么建议大家把函数拆小？不是教条，是因为人的工作记忆有限。一个函数里同时处理三件事，读代码的人就得同时记住三套逻辑，太累了。拆成三个小函数，每读完一个小函数清空一次缓存，理解成本成倍下降。

11. 一个函数只做一件事，从函数名就能判断出来。
save_user_and_send_welcome_email 这种“和事佬”函数就该拆成 save_user 和 send_welcome_email，调用方按需调用。判断标准很简单：如果你在描述这个函数时用了“顺便”“同时”这些词，大概率该拆了。

12. 函数体尽量控制在“一屏能看完”的范围。
不是硬性规定必须 20 行以内，而是超过一个屏幕后，阅读时就要来回滚，心流会被打断。真遇到逻辑必须长的函数，优先检查是不是塞进了太多“顺便”逻辑。另外，单个函数里的缩进层级控制在 2 层以内，出现 3 层甚至 4 层，说明嵌套太深，要么提取子函数，要么用统一的空值策略提前返回。

2.2 参数设计：少传参，不裸传

函数参数是调用方和实现方的契约，参数越多，契约越复杂。我倾向把参数数量控制在 3 个以内，再多就考虑把它们包成一个有语义的对象。

13. 超过 3 个参数就考虑用对象/结构体打包。
比如 create_user(name, email, age, gender, phone)，调用方每次都要按顺序传，少一个、错一个都不行。改成 create_user(UserCreateRequest(...))，参数之间有了名字，可读性提升一个档次，以后加字段也不用改函数签名。

python复制# 不好
def create_user(name, email, age, gender, phone):
    ...

# 好
class UserCreateRequest:
    def __init__(self, name, email, age, gender, phone):
        ...

def create_user(request: UserCreateRequest):
    ...

14. 能用默认参数就设默认值。
def get_user(user_id, include_profile=False)，大多数调用方不需要 profile 时就不用管第二个参数。默认参数能让调用保持简洁，同时保留扩展能力。但要小心不要在公共 API 里把默认值设成可变对象，比如 def add(item, items=[])，这是 Python 的经典坑，默认列表会被多次调用共享。

15. 不要用裸布尔参数控制函数行为。
send_email(user, True) 里的 True 是什么？得去看函数定义才知道。改成 send_email(user, is_html=True) 可读性会好很多，或者干脆拆成两个函数，send_text_email 和 send_html_email。裸布尔是隐藏的设计坏味道，它往往意味着这个函数内部有两条不相关的路径。

2.3 避免重复与保持返回契约稳定

重复代码和返回类型不稳定，是我在代码评审里最常抓的两个问题。前者让同一个改动要改多个地方，后者让调用方永远不确定自己拿回来的是什么。

16. 重复代码一定要提炼，别 Ctrl+C/V。
遇到三处以上相似代码，抽成公共函数或公共模块。这也是“优化代码重复删减脚本”这类诉求背后的本质：不是靠脚本去删，而是靠设计避免重复产生。三处以内可能还能忍，到了三处以上，后面每次修改都是多处同步改，迟早会漏。

17. 函数返回类型要稳定，尤其不要忽而是对象忽而是 null。
要么在返回前就抛异常、快速失败，要么用 Optional / 空对象。让调用方每次都要 if result is None 才能往下走，是一种慢性折磨。Java 8 以后可以用 Optional，Python 里可以用 Optional 类型注解，Go 里则约定返回 error，建立一套团队都认同的约定比具体用哪个更重要。

18. 不要直接暴露内部可变引用。
如果一个类里维护了一个 list，直接 return self.items，外部就可以不经由类方法直接修改它。这是封装失效的常见原因。要么返回只读视图，要么返回一个拷贝，或者用迭代器接口。数据结构的“门卫”没做好，状态就失控了。

3. 条件表达与错误处理：让分支不再像迷宫

写代码时我发现，真正的复杂度往往不在主路径上，而在分支上。条件语句嵌套太多，代码读起来就像走迷宫；错误处理稀里糊涂，出了事又像在黑暗里摸电闸。这两块做好了，代码的“稳”和“顺”就都出来了。

3.1 用卫语句和谓词函数挡住深层嵌套

卫语句是我最想推荐给所有开发者的一个习惯，因为它立竿见影。所谓卫语句，就是在函数开头把不符合条件的情况直接返回，而不是每个分支再继续往里嵌套。

19. 用卫语句提前返回，代替深层 if 嵌套。
看这个例子：一个函数先判断用户非空，再判断用户是否有权限，然后才执行业务。如果用嵌套写，五层 if 之后真正的业务代码缩进到天花板了。改成卫语句，先判空，再判权限，不满足就 return，主逻辑就平铺在最后。

python复制# 不好
def get_user_profile(user):
    if user is not None:
        if user.has_permission:
            return build_profile(user)
    return None

# 好
def get_user_profile(user):
    if user is None:
        return None
    if not user.has_permission:
        return None
    return build_profile(user)

20. 把复杂条件提取成谓词函数。
一个 if 后面跟了五六个 and、or，就算勉强看得懂，改一次也费劲。把这个长条件提取成一个函数，名字写清楚含义，比如 is_valid_order(order)，调用处读起来像自然语言，逻辑变了也只改一处。

3.2 空值处理和快速失败

空值大概是代码缺陷里最大的来源之一。处理空值最糟糕的方式就是到处 if x is not None，然后套一层又一层。我认为正确的思路是围绕团队约定，建立统一的策略，要么快速失败，要么用空对象。

21. 尽早校验外部输入，不满足条件就快速失败。
函数入口处就把非法参数挡住，不要让它们流转到中途才发现。比如 C 语言里做文件读写，fopen 返回 NULL，很多新手直接往下 fwrite，程序崩溃了都不知道为什么。入口处加一句对返回值的检查，问题就能在上游暴露。

c复制FILE *fp = fopen("data.txt", "r");
if (fp == NULL) {
    fprintf(stderr, "open data.txt failed\n");
    return -1;
}

22. 用 dict.get、defaultdict 这类工具消除重复判空。
Python 里 dict.get(key, default) 可以避免 if key in d: return d[key] else: return default 这种样板代码；需要修改值时，collections.defaultdict 又能省掉“先判断是否存在再初始化”的步骤。这类内置工具是在帮你把平凡的事情收敛成一行，读起来干净很多。

23. 统一空值策略，不要在代码里混用多种风格。
有的地方返回 None，有的地方抛异常，有的地方返回空对象，调用方就疯了。选一种，定成团队约定：比如“查询类方法查不到就返回空对象”；“校验类方法失败就抛异常”。统一了之后，读代码的人不需要每次根据函数猜返回值。

3.3 异常处理的正确姿势

异常处理最容易走两个极端：一个是到处抓异常又什么都不干，一个是完全不处理让程序崩掉。两者都很危险。我见过最迷惑的代码就是 try 包一大块，except 里写个 pass，等于把错误吞掉了，调问题时一脸茫然。

24. 不要吞掉异常，至少要记录日志。
如果这个异常真的不影响主流程，也请你写一行注释说明“为什么可以忽略”，并在日志里留下痕迹。不然线上出了诡异问题，排查的人只能把整个函数一行行读完才能发现这里有个黑洞。吞异常一时爽，排查火葬场。

25. 抛出异常时要携带上下文信息。
不要只写 raise ValueError()，读日志的人不知道哪里的值非法了、非法的值是什么。写成 raise ValueError(f"user_id 不能为空，请求参数: {params}")，排查效率直接提升一个数量级。异常信息是给未来的人看的日志，不是留给自己的回旋余地。

26. 不要用错误码满天飞来代替异常，除非是语言习惯。
在 Go 里你被迫写 if err != nil，这是语言哲学；但在 Java、Python、C++ 里，用异常表达错误更清晰。一个函数返回 -1、0、1 表示不同错误，调用方就得记一张密码表。能用异常或 Result 类型表达，就别用魔法数字。

4. 数据结构与算法：让代码既快又短的习惯

代码优雅不只是“看起来爽”，很多时候合理的结构和算法，会让代码量直接减半，性能也跟着上去。这一章不聊复杂竞赛题，只聊日常开发里最常见的几个数据结构和处理套路。你的大部分业务逻辑，无非是集合的增删改查、排序、去重、查找。

4.1 选对数据结构，胜过十行手写逻辑

选对数据结构是“少写代码”的关键。很多时候我们埋头写循环，其实是手头选错了容器。一个简单的例子：判断一个元素在不在集合里，用列表要 for 循环遍历，时间复杂度 O(n)；换成一个 set，一次查找 O(1)，代码还短。

27. 频繁查找用 set/dict，不要用 list 硬扛。
去重、成员判断、按 key 取 value，这些都是高频操作。用 set 或 dict 不仅能大幅提升性能，代码也更简短。比如统计一段文本里出现过的单词，word_set = set(text.split()) 一行就完了，用列表模拟还得写十几行。

28. 善用 collections.defaultdict 消除初始化样板。
统计词频时，传统写法是先判断 key 在不在字典里，不在就初始化为 0，然后加一；用 defaultdict(int) 之后，直接 counter[word] += 1 就完事。初始化逻辑被内建工具接管，你的脑子里只需要关注业务。

python复制from collections import defaultdict

# 不好
counter = {}
for word in words:
    if word not in counter:
        counter[word] = 0
    counter[word] += 1

# 好
counter = defaultdict(int)
for word in words:
    counter[word] += 1

29. 能用推导式用推导式，但别写出“天书”级复杂度。
Python 的列表推导式、字典推导式很优雅，一行搞定一个循环加条件过滤。但谨记可读性优先，三层嵌套加三个 if 的推导式，别人根本看不懂，还不如老老实实写 for 循环。一层的推导式是糖，三层的推导式是毒药。

30. 排序时用 key 函数而不是写自定义比较器。
Python 的 sorted() 和 list.sort() 支持 key 参数，比如按学生年龄排序直接 sorted(students, key=lambda s: s.age)。面试题里考“快速排序代码”是要你懂原理，但工程代码里请直接拥抱标准库，稳定、高效、还能省掉你调试边界条件的痛苦。

4.2 去重、遍历与递归的取舍

31. 去重要保留顺序时，用 dict.fromkeys 或类似手法。
set 去重很快但会打乱顺序，业务上常常要求“去重但保持原序”。Python 里可以用 list(dict.fromkeys(items))，字典在插入顺序上保留了输入顺序，这个技巧简洁又高效。

32. 遍历多个集合时，用 enumerate、zip 替代索引下标。
需要同时拿到下标和值时，for idx, item in enumerate(items) 比 for i in range(len(items)) 清楚。两个列表同步遍历时，for a, b in zip(list_a, list_b) 也是一行解决。手写索引不仅容易越界，读起来也费劲。

33. 递归注意边界条件，能用迭代就用迭代。
递归代码看着简洁，比如树的先序遍历，但深度一上来容易爆栈。工程上写递归一定要两个东西：清晰的终止条件，和明确的递归状态。如果发现递归深度不可控，大概率要用显式栈或迭代重写。性能敏感的场景里，迭代往往比递归更稳。

34. 对外暴露数据时，考虑返回不可变对象或只读视图。
外部拿到内部 list 后原地修改，是很多诡异 bug 的来源。Java 可以用 Collections.unmodifiableList，Python 可以返回 tuple 或副本。数据结构的“门卫”没做好，状态就失控了。这个习惯能帮你挡住很多“运行时才知道数据被改了”的灵异事件。

5. 性能与资源：不牺牲可读性的优化手法

性能优化最怕的是过早优化，为了省那几微秒，把代码写成天书，得不偿失。但有一些零成本的小习惯，既不会伤害可读性，又能避免明显的性能大坑。这一章聊的是这类“顺手就做了”的优化。

35. 循环外提，减少重复计算。
如果循环体里有一个计算跟循环变量无关，把它移到循环外面。比如 len(items) 本来可以在循环前取一次，就不要每次进循环都算一遍。优化编译器可能会帮你做，但你自己做会更明确，代码也更好读。

36. 字符串拼接用 join，不要在循环里用加号。
Python 里 str1 += str2 在循环里会反复创建新字符串，用 "".join(s_list) 一次拼好性能更好。Java 里则用 StringBuilder。这个习惯不仅在量大的时候能看出明显差异，也会让代码更干净地表达“我是在拼接一批内容”。

python复制# 不好
s = ""
for part in parts:
    s += part

# 好
s = "".join(parts)

37. 预先设计好集合的容量，减少扩容。
Java 里 new ArrayList<>(1000)，Python 里如果知道范围可以用列表乘法预留空间。这一条能优化一点性能，但更重要的是体现了你对数据规模的预估，反过来会推动你思考边界条件。

38. 用缓存和懒加载，避免重复计算。
同一个对象在同一批请求里被反复计算同样的值，可以用缓存。最简单的是函数内局部变量，复杂一点可以用字典做 memo，或者用 functools.lru_cache 装饰器。懒加载则是指“用到了才初始化”，避免启动时加载一堆用不到的重量级资源。

39. 不要在循环里做 IO 和网络请求。
数据库查询、HTTP 调用、文件读写，这些操作的开销是内存计算的几个数量级。循环里逐个查库，N 次请求就是 N 倍的网络时延；改成批量查询或提前拉取到内存，体验立竿见影。这条对任何语言都适用，也是后端性能优化最值得看的地方。

40. 先写对再优化，用 profile 定位热点。
“这段到底哪慢？”不要靠猜。先用 profiler 跑一遍，找到真正的热点，再针对它优化。过早优化不仅浪费时间，往往还优化错了地方。代码可读性永远排第一，性能排在正确性之后，这是所有工程项目的常识。

41. 用生成器或迭代器减少内存占用。
Python 处理超大文件时，for line in f 是逐行读入的，不会把整个文件加载进内存；处理大量数据时，用生成器表达式比构建一个大列表省内存。这个习惯在数据量上来时能救你于内存 OOM 的尴尬。

42. 优先用标准库和成熟方案，少自己造轮子。
标准库里 sorted、re、datetime、json 这些已经经过大量优化和测试，用它们比手写快得多也稳定得多。自己实现序列化、日期解析、排序，大概率写得又慢又容易出 bug。这不是说不要理解原理，而是工程上要相信“站在别人肩膀上”。

6. 注释、文档与代码整理：让代码活得久

代码只要还在生产环境跑，就是“活”的。活的项目一定会有需求变更、bug 修复、人员交接。这一章讲的是让代码活得久、交接得顺的习惯。注释不是越多越好，文档也不是越厚越好，关键是写到点子上。

6.1 注释写“为什么”，不写“是什么”

我见过很多注释在复述代码行为：i++ // 让 i 加一，这等于废话。真正有价值的注释，是解释代码背后的原因和约束。

43. 注释解释“为什么”而不是“是什么”。
当你写下一段看起来“绕”的代码时，注释应该告诉后人这是为了绕开哪个坑。比如“这里先查缓存再查库，因为 XXX 接口较慢”，这种信息无法从代码本身读出，才是注释的价值。单纯翻译代码的注释，删掉反而更清爽。

44. 注释掉的死代码，一律删掉。
有人喜欢把暂时不用的代码注释掉，留在原地当备用。但版本控制已经保留了历史，旧代码要找都找得到，留在代码块里只会增加阅读负担。怕丢就交给 Git，代码里只留能跑的东西。

45. docstring/文档注释写清输入输出和边界。
公共函数、类、模块应该有一段说明：参数是什么，返回什么，什么时候会抛异常，有什么前置条件。不必写论文，三五行就好。读者调用之前扫一眼，就知道能不能用、怎么用，不用翻进函数体看实现。

6.2 代码整理：让“风格不统一”不再成为问题

代码风格的争论是最浪费时间的事之一。与其在 code review 里争缩进用几个空格，不如直接上格式化工具，把争议交给机器。

46. 用自动格式化工具统一风格。
Python 用 black，Go 用 gofmt，Java 用 google-java-format，前端用 prettier。这些工具的好处是所有人都遵守同一套格式，diff 干净，review 集中在逻辑而不是格式。第一次跑格式化可能会有巨大的 diff，但之后就一劳永逸了。

47. 顺手清理“无用代码”：未使用的 import、变量、死分支。
IDE 会给出灰色警告，静态分析工具会提示，但最关键的还是习惯。每次提交前，删掉没用到的 import，删掉没走到的分支，删掉注释掉的片段。长期坚持，代码库的体量会保持在一个可控范围，不会像熵增一样变乱。

7. 工具链与协作：让优雅变成团队习惯

个人写代码有很多自由，但一旦到了团队，就需要工具来维持秩序。好的工具链能把你从腌臜事里解放出来，把精力花在真正的逻辑上。这一章聊几个我用下来觉得对代码质量帮助很大的工程化手段。

7.1 用静态检查和诊断工具提前发现坏味道

48. 让静态分析工具做代码诊断，别等 bug 自己冒出来。
SonarQube 可以扫描本地代码，ESLint、Pylint、Go Vet 也都有类似的定位。它们能发现潜在的 null 指针、明显的 bug、复杂度超标、重复代码等。这类工具的价值在于“提前”，人眼总会有盲区，机器不会。我一般在 CI 里挂一道静态检查，不过就不过合并。

7.2 让 AI 辅助改代码，但人必须把关

49. 用 AI 工具修改已有代码时，看懂了再合入。
现在 AI 生成代码已经很常见，比如用 Codex 之类的工具补全函数、重构小段逻辑，效率确实高。但我的原则是：让 AI 写之前先想清楚边界，它改完之后，必须逐行读一遍，确认逻辑符合自己的预期。AI 生成代码最大的风险是“看起来对，实际上偷换了语义”。

另外，要求 AI 干活时尽量给出具体上下文和需求约束，而不是一句模糊的话。你给的信息越清晰，它生成的代码越接近你要的东西。拿到之后，补几条测试用例跑一下，比自己盲目信任 AI 靠谱得多。

7.3 提交与分支：让每一笔改动都有迹可循

50. 小步提交，写清 commit message。
一次提交对应一个逻辑变更，不要积攒三天再一次性提交成一个 500 行的大 diff。commit message 不要写 fix、update，要写清楚“为什么改、改了什么”，比如 fix(login): 修复邮箱大小写导致登录失败的问题。等你需要 git bisect 排查线上问题时，会发现清晰的提交历史能救命。

如果用的是 Gitee 这类平台，把本地分支推到远程仓库时，确认好远程地址和分支名，先 git remote -v 看看配得对不对，再 git push -u origin main，可以省掉一堆“推错仓库”“推到别的分支”的事故。

8. 实战中的高频坑：几个让你排查到怀疑人生的场景

前面 50 个技巧说完了，最后分享几个我实际帮人排查时反复遇到的场景。它们不是代码本身的问题，但新手经常在这里卡很久，值得记一下。

8.1 VS Code 里写 C 语言没有代码提示

很多人一开始写 C，用 VS Code 打开 `.c