有人看到"Python基础语法记录"这个标题，第一反应可能是：基础语法有什么好记的？官方文档翻一翻不就行了。我早年也这么想，直到有一次，一位同事把可变列表当成函数参数的默认值，线上数据被悄悄污染，日志里没有任何报错，折腾到凌晨才定位到问题。从那以后我改变了一个看法：所谓基础，恰恰是最容易想当然的地方。这篇记录不是把教程抄一遍，而是我在实际写 Python 的过程中反复验证过的结论——哪些写法会埋坑、哪些行为反直觉、生产环境里怎么规避。适合刚开始学 Python 的读者建立正确认知，也适合已经写了一阵子但没系统回看过基础的开发者查漏补缺。
1. 从缩进开始：语法层面最容易被轻视的约束
1.1 缩进是语法，不是风格
刚从 C 语言或者 JavaScript 转过来的朋友，很容易把 Python 的缩进当成一种"排版习惯"：代码看起来整齐就行。其实在 Python 里，缩进是语法的一部分。解释器靠缩进来判断代码块从哪里开始、到哪里结束，缩进错误直接抛 IndentationError，程序根本跑不起来。
当初设计成缩进而不是花括号，出发点很明确：强迫所有人写出结构一致的代码，同时让源码本身就能表达嵌套关系。你可以不喜欢这个设计，但既然进了 Python 这门语言，就得按它的规矩来。
实际操作中，我的建议是统一用 4 个空格做缩进，并把编辑器的 Tab 键配置成"插入空格"。原因很现实：Tab 键在不同编辑器和终端里显示的宽度不一样，同一份代码在 A 编辑器里看着对齐，换到 B 编辑器可能就乱了。空格是确定的，永远不会因为渲染环境变化而改变。
1.2 三类常见的缩进报错
第一类是混用 Tab 和空格。文件里看着差不多，但运行时报 TabError 或 IndentationError。老项目里很常见，尤其是经历了多人维护、不同编辑器流转的脚本。排查方法很简单：把编辑器设置成"显示空白字符"，Tab 和空格立刻现出原形。
if is_valid: print("Tab 缩进") print("空格缩进") # 混用之后解释器直接报错第二类是在不该加缩进的地方多加了缩进。比如 if 判断的下一行代码原本在块外，手滑多按了一下 Tab，程序可能不会立刻报错，而是逻辑变了——这是更隐蔽的情况，因为代码能运行，只是运行结果不对。遇到"代码没报错但行为怪"的 bug，先检查缩进有没有改变块的范围。
第三类是续行的对齐问题。括号、方括号、花括号内部的换行是隐式续行，缩进比较自由；但用反斜杠显式续行时，反斜杠后面不能有任何字符，包括注释和空格，否则注释会被继续拼进上一行，导致语法错误。这个小细节在从网页复制代码时特别容易踩到。
提示: 想快速检查一个文件有没有语法问题，可以执行
python -m py_compile 文件名.py，不需要把程序完整跑起来。
2. 变量与对象：把"名字"和"值"分开理解
2.1 变量是标签，不是盒子
很多新手对变量的理解是"一个装值的盒子"，Python 里更准确的理解是：变量是贴在对象上的标签。执行a = [1, 2, 3]，等于创建了一个列表对象，然后把标签 a 贴上去。再执行b = a，并不是复制对象，而是把同一个对象再多贴一个标签。
区分这两个概念最直接的工具是id()，它返回对象在进程内的唯一标识；或者用is判断两个名字是否指向同一个对象。同样要理解的是==比较的是值是否相等，is比较的是身份是否相同。日常写代码，除了和None比较用is None，其他情况应该用==。
举个典型例子：
a = [1, 2, 3] b = a b.append(4) print(a) # [1, 2, 3, 4]如果你以为 b 是 a 的副本，这个结果会很意外。生产环境里这类问题经常出现在"把一个列表传给函数，函数内部做了修改，调用方发现原数据变了"的场景。
2.2 可变与不可变对象的行为差异
Python 的对象按"能不能原地修改"分成两类：列表、字典、集合是可变对象，可以往里面加东西；整数、浮点数、字符串、元组是不可变对象，任何"修改"操作实际都是创建新对象。这个差异带来一条很实用的规则：把可变对象传进函数时，函数内部容易"顺手"改掉外部数据。如果你不想让函数改原数据，就传副本。
import copy original = [[1, 2], [3, 4]] shallow = original[:] # 外层是新列表，内层还是同一个 deep = copy.deepcopy(original) # 内层也复制了一份浅拷贝和深拷贝的区别也经常被忽略。list[:]、list.copy()、dict.copy()都是浅拷贝：只复制最外层容器，里面嵌套的列表、字典仍然共享。修改内层元素，原数据还是会变。真正要隔离，用copy.deepcopy。这个细节在做配置快照、批量修改数据时非常关键。
2.3 动态类型带来的便利和代价
Python 是动态类型语言，变量不需要声明类型，同一个变量先存整数再存字符串也不会报错。便利的同时也带来一个代价：很多问题直到运行到某一行才会暴露。比较典型的是从文件里读出来的"数字"，其实是字符串，直接拿去和整数比较，结果永远为 False，而且不会有任何提示。
在这种场景下，判断类型用isinstance而不是type。不是说type不对，而是isinstance会考虑继承关系，更符合实际的类型体系。另一个常见需求是把"可能为 None 也可能为正常值"的对象分开处理，这时候鸭子类型的思想很有用——只要对象具备你要用的行为，满足行为就行。
注意: 动态类型的隐患不一定要靠运行时碰运气来解决。给函数参数和返回值加上类型注解，配合类型检查工具，能在写完代码后立刻发现一批问题，又不影响程序运行时的行为。
3. 控制流：条件判断和循环里那些容易忽略的细节
3.1 真值判断：if 后面的东西到底代表什么
写条件判断时，很多人只记得"相等比较"，却忽略了 Python 有一套隐式真值规则。下面这些值在布尔上下文里都是 False，其他值是 True：
| 表达式 | 真值 | 常见场景 |
|---|---|---|
0/0.0 | False | 数值判断 |
''/"" | False | 空字符串 |
[]/{}/set() | False | 空容器 |
None | False | 缺失值 |
| 其他非空对象 | True | 一般情况 |
所以下面这样写是合法的，而且很常用：
if items: # 列表非空 ... if not name: # 字符串为空 ...真正需要注意的是一个容易混的点：
if x is None: # 只判断是否为 None if not x: # 判断真假值，0、''、[] 都会走到这里 if x is not None: # 非 None 才成立有时候你只想区分"有值还是没有值"，但是用not x会把0也当成"没有"，如果 0 是合法业务数据，结果就错了。正确姿势是：判断是否缺失用is None，判断容器是否为空用not container，两边别混。
另外，Python 支持链式比较a < b < c，它等价于a < b and b < c，而且中间的表达式只会计算一次。这个语法在读范围判断时非常直观，比如0 <= score <= 100，比写score >= 0 and score <= 100清爽不少。
3.2 for 循环：比表面看起来多出来的几个用法
for 循环最常见的误区是"在循环里修改正在遍历的列表"。比如想把列表里的负数全部移除，一边遍历一边用remove，会发现结果和预期差得离谱，原因是遍历过程中列表的元素位置在不断变化。稳妥做法是遍历列表的副本，或者用一个新列表收集要保留的元素：
numbers = [-1, 2, -3, 4] for n in numbers[:]: # 遍历的是副本，原列表可以放心删 if n < 0: numbers.remove(n)另一个容易忽视的是 for 循环可以和 else 搭配使用。else 块在循环正常结束（没有执行 break）时才会执行。这个语法在"查找目标，找到就 break，没找到要给出提示"的场景里非常好用，比用一个标志变量干净很多：
for item in items: if item == target: break else: print("没找到")遍历字典时，默认遍历的是键，如果你想要键值对，要显式用.items()。这个细节看似简单，但在把数据从 JSON 结构里提取出来时，写错了往往会拿到一堆键导致业务逻辑混乱。
3.3 while 循环：什么时候值得用
while 循环在 Python 里被我使用的频率远低于 for，但它有两个不可替代的场景。一个是"条件在循环过程中才变化"的情况，比如直到用户输入合法值为止；另一个是需要死循环配合 break 退出的情况。常见写法：
while True: line = input("请输入：") if line == "q": break用 while 最怕的是忘记改循环变量，或者改了但条件永远满足不了，程序直接卡死。调试这类问题，我的习惯是把循环次数的上限打印出来，先让程序能终止，再逐步修正条件。
4. 函数：参数、作用域与默认值里的经典深坑
4.1 参数传递：值、引用还是"对象引用"？
函数参数的传递方式，是 Python 基础里争论最多的问题之一。直接给结论：Python 传的是对象引用。意思是，函数拿到的是外部对象的一个引用，而不是对象的拷贝；在函数里给参数重新赋值，不会影响外部的变量；但如果函数修改了参数指向的可变对象本身，外部就能观察到变化。
def change(lst): lst = [1, 2, 3] # 重新绑定，外面不受影响 def append_item(lst): lst.append(1) # 原地修改，外面能看到 data = [0] change(data) print(data) # [0] append_item(data) print(data) # [0, 1]理解了这一点，很多"函数改了外部变量"的诡异事故都说得通了。想避免意外修改，要么在调用方传入副本，要么在函数内部一开始就复制一份再处理。
4.2 可变默认参数：新手最容易埋下的雷
如果让我只选一个"最值得写进基础语法笔记的坑"，就是可变默认参数。看这段代码：
def add_item(item, items=[]): items.append(item) return items print(add_item(1)) # [1] print(add_item(2)) # [1, 2]，而不是 [2]函数定义只会执行一次，默认参数items=[]在定义那一刻就被创建，之后所有调用共享同一个列表。于是第二次调用时，上一次的数据还在里面。这个 bug 的可怕之处在于：单次调用看不出问题，放在循环或多次请求里才会暴露，排查起来非常费劲。
标准解法是用 None 作为占位，函数内部再创建新列表：
def add_item(item, items=None): if items is None: items = [] items.append(item) return items这里 None 是不可变对象，不会出现跨调用共享的问题。凡是默认值可能被修改的参数，都建议用这个模式。
4.3 作用域规则：LEGB 与"未定义却报局部变量"
Python 查找名字的顺序大致是 LEGB：局部作用域、闭包外层函数作用域、全局作用域、内建作用域。读取一个全局变量在函数内部是允许的，但一旦你在函数里对某个名字做了赋值操作，Python 就会把整个函数里的这个名字都当成局部变量。结果是在赋值之前读取它，会报UnboundLocalError：
count = 0 def inc(): count += 1 # 报错：count 被当成局部变量，但还没定义 inc()这个错误很反直觉，因为明明外面定义了 count。解法是在函数里声明global count，或者更推荐的做法是别改全局变量，用参数传入、返回值传出。嵌套函数里要修改外层函数的变量时，用nonlocal，规则和global类似。
还有一个和闭包相关的经典问题：在循环里创建 lambda 函数，结果所有函数捕获了循环变量最后的值。比如：
funcs = [lambda: i for i in range(3)] print([f() for f in funcs]) # [2, 2, 2]这是因为 lambda 在调用时才去外层作用域取 i，而循环结束后 i 已经是 2。想要捕获当前值，可以用默认参数绑定的技巧：lambda i=i: i。
4.4 函数参数设计：让调用方不容易用错
参数设计看似是风格问题，实际影响产品质量。我的经验是：能用具名参数表达意图的，就别让调用方靠位置猜。Python 提供了关键字专用参数语法，在参数列表中用*分隔：
def connect(host, port, *, timeout=5): ... connect("127.0.0.1", 8080, timeout=10) # 清晰*args和**kwargs适合做转发包装的场景，但不要为了"灵活"而让所有参数都变成可变长参数，那样函数签名就失去了信息量。给可能传默认值的参数设置合理默认值，给布尔开关取明确名字如use_cache而不是flag，这些习惯比任何高级语法都更能减少线上返工。
5. 常用数据结构：选型、取数与修改的实操记忆
5.1 元组 vs 列表：不只是"不能改"
元组和列表的区别，表面看是能不能修改，实际影响更深。元组是可哈希的（只要里面的元素都可哈希），这意味着元组能当字典的键、能放进集合，而列表不行。如果你有一组固定字段想作为字典键，比如坐标(x, y)，用元组天然合适。
另一个元组的高频用途是解包：
x, y = point first, *rest = numbers还有namedtuple，它让元组的字段有名字，兼具元组的轻量和类对象的可读性，在需要快速定义小数据结构的场景比写一个 class 省事。需要注意：元组里如果放了列表，这个元组虽然不能增删元素，但内部列表仍然可以修改，所谓"不可变"并不是完全彻底。
5.2 字典：取数、缺省与计数的正确姿势
字典最典型的错误是用方括号直接取键，键不存在就抛 KeyError。如果你不确定键是否存在，优先用.get(key, default)：
name = user.get("name", "未知用户")需要往里塞数据时，setdefault可以避免"先判断再赋值"的两步操作，但它的写法容易让人困惑。在计数场景里，我更推荐直接使用collections.Counter或defaultdict：
from collections import Counter, defaultdict words = Counter(text.split()) groups = defaultdict(list) groups["a"].append(1) # 键不存在会自动建一个空列表字典还有一个经常被我用到的小知识点：从 Python 3.7 起，字典保持插入顺序，遍历时看到的顺序就是键第一次被插入的顺序。做数据缓存、保持配置顺序时很省心。
5.3 集合：去重之外的关系运算
很多教程把集合只当作"去重工具"，其实它的真正价值是集合关系运算：交集、并集、差集。比如判断两个用户群组的权限是否有重叠，用集合运算符一行搞定：
a = {"read", "write"} b = {"write", "execute"} print(a & b) # {'write'} 交集 print(a | b) # 并集 print(a - b) # {'read'} 差集集合要求元素可哈希，所以想给集合放列表得先转成元组。另一个容易踩的坑是：集合本身无序，别指望遍历顺序和插入顺序一致。要既保证不重复又保证顺序，可以用字典的键实现，或者手动维护一个列表加集合的组合。
5.4 推导式和生成器：表达力与内存的取舍
列表推导式是我最喜欢的语法之一，它把"建一个新列表、遍历、过滤、添加"压缩成一行，可读性反而更好：
squares = [x * x for x in range(10) if x % 2 == 0]但推导式嵌套超过两层，就很难读了。遇到复杂逻辑，宁可老老实实写 for 循环。另一个关键是生成器表达式——把方括号换成圆括号，它不会一次性生成所有元素，而是惰性计算。处理几万条日志、超大文件的行时，用生成器表达式能省下大量内存：
total = sum(len(line) for line in open("large.log"))注意函数调用里只有一个参数时，生成器表达式的括号可以省略，这个语法细节在写sum、any、all时很常见。
6. 异常与调试：让报错信息帮你而不是吓你
6.1 try/except/else/finally：这四个块各干各的事
异常处理是每个 Python 开发都得掌握的语法组合，但很多人只用到 try 和 except。完整结构是：
try: do_something() except ValueError as e: handle_value_error(e) except TypeError: handle_type_error() else: print("没有异常时执行") finally: cleanup()几个容易被忽略的规则：不要写裸except:，它会连键盘中断、系统退出这类异常也吞掉；捕获具体异常时，子类要写在父类前面，否则子类永远轮不到；else块在 try 正常完成时执行，适合放"只有成功才需要做"的代码；finally无论是否异常都会执行，适合放关闭文件、释放连接这类清理操作。
6.2 学会从上往下读异常栈
新手看到一长串报错直接懵，其实 Python 的 traceback 是有顺序的：最上方是调用链的入口，最下方是真正出错的那一行。我建议先看最后几行，明确出错的文件、行号和异常类型，再回头看调用链，理解错误是从哪一层冒出来的。
常见误区是只看最后一句的错误信息就急着改代码，实际上问题往往在更早的调用中。比如一个函数返回了 None，后面代码对 None 做操作报 TypeError，真正要修的是函数返回 None 的逻辑，而不是后面的调用处。
6.3 遇到奇怪行为时，先验证而不是先猜
写基础语法笔记的时候，我最大的体会是：很多"灵异现象"其实都是对某个语法行为的错误假设。遇到解释不通的行为，不要靠猜，先写几行最小测试代码验证：
print(repr(value)) # 用 repr 而不是直接 print，能看到字符串里的换行和空格用repr是调试的一小步，却是避坑的一大步。第二个操作是随手查一下函数的签名和默认行为，比如range(len(items))与enumerate(items)的差异，str.split()默认按空白拆分等，这些细节背不下来很正常，用时确认一遍即可。最后，善用 Python 交互式环境做快速实验，把想法跑一遍再写进正式代码，比一遍遍整体运行调试快得多。
我后来习惯把这类基础语法记录保存在自己的笔记里，每次入职新项目、接手老旧代码之前都会快速过一遍。至少从团队这两年的效果看，因为可变默认参数和缩进问题导致的 bug 明显少了很多。真正值得记录的，从来不是那些 API 怎么调用，而是这些藏在基础之下的坑——它们才是在生产环境里消耗时间最多的地方。
