有朋友私信问我Python学到第18天应该是什么状态。我的回答是这是一个最容易让人又爱又恨的节点。前两周你大概已经把变量、循环、函数、字符串处理这些基础语法摸熟了能写小脚本处理重复劳动可一旦面对稍微复杂一点的业务——比如订单、用户、商品这些真实概念要一起塞进代码里——就会觉得到处都是散落的变量和函数改一个功能牵一发动全身。如果你也有这种感觉那day18这门课来得正是时候。这一天的内容几乎全部围绕面向对象编程展开解决的核心问题只有一个怎么用类把数据和操作打包在一起让代码从“能跑”变成“经得起改”。这篇文章按我实际的备课和带练思路整理适合两种人看一种是把基础语法过完、正准备啃面向对象的新手另一种是已经会用类、但想系统梳理类方法、属性管理、继承细节的进阶读者。我不会只贴概念会把每个知识点的原理、代码、判断标准、坑位全部摊开讲你跟着敲一遍基本就能把这一天的内容吃透。1. 为什么第18天要开始“啃”面向对象1.1 从“函数堆叠”到“类封装”的思维转变前17天你做的事情本质上是在“堆函数”。拿一个图书管理的小需求来说你用函数写可能是这个画风books [] def add_book(title, author, price): books.append({title: title, author: author, price: price}) def search_book(keyword): for book in books: if keyword in book[title]: return book return None这种写法在程序小的时候完全没问题全局变量加函数组合直来直去很好理解。但代码一旦膨胀问题就来了books 这个全局列表谁都能改某天你在一个回调函数里不小心写成了books []局部变量把全局引用遮蔽掉程序就开始出现匪夷所思的“数据消失”现象。更麻烦的是每一本“书”都是一个字典字典的 key 靠开发者自觉维护有人写title有人写titel数据格式一乱所有处理函数跟着遭殃。面向对象解决的就是这一类问题。类把“书”这个业务概念固化成一种自定义数据类型书该有哪些字段、该提供哪些方法都在类定义里写明白了外部只能通过你暴露的方法去操作数据。从这个角度说类就是一种“更结实的字典”从这个角度说类就是一种“更结实的字典”只不过它不仅约束数据的结构还把行为也绑在一起。1.2 这一天的学习目标拆解day18作为进阶阶段的开篇课程目标其实可以拆成四个层次难度是递增的第一层能写出一个结构完整的类。这个类包含__init__构造方法、几个实例字段、至少一个业务方法并能正确实例化出多个互不干扰的对象。第二层能区分实例方法、类方法、静态方法三种定义方式知道每种方法什么时候用self、什么时候用cls、什么时候什么都不用并且能在实际代码里做出合适选择。第三层能理解属性访问的底层机制会使用property给字段加入校验逻辑知道__slots__能限制实例可以拥有的属性、减少内存开销。第四层能理解继承、方法重写、super()调用的协作关系并能用几个常见的魔术方法让自定义对象支持len()、in、for循环等原生操作。这四个层次分别对应类的基本形态、方法体系、属性管理、类关系与协议几乎涵盖了 Python 面向对象中最常用的基础能力。把这四层吃透后面学进阶设计模式、框架源码都会顺很多。1.3 为什么选择“类封装”而不是其他思路有读者会问Python 也有dataclass能自动生成初始化方法和比较方法是不是可以跳过手写__init__直接学那个我的建议是day18阶段先不要跳。dataclass是一个很棒的工具但它帮你省掉的恰好是理解构造过程的机会。如果你不知道手写的__init__里发生了什么就很难理解self到底是什么、实例属性和类属性有什么区别。更关键的是许多第三方库的源码大量使用原生类的写法源码阅读能力就是从读懂__init__和self开始的。先老老实实写原生类把机制弄明白之后再拥抱dataclass这类语法糖会非常轻松。2. day18的核心动作先搭一个类出来2.1 写第一个类的完整流程这一节我直接带你把一个类从零搭出来就以上面提到的“图书”为例。第一步是定义类的骨架包括类名、构造方法和实例字段class Book: def __init__(self, title, author, price): self.title title self.author author self.price price def info(self): return f《{self.title}》 by {self.author}定价 {self.price} 元 def apply_discount(self, rate): self.price round(self.price * rate, 2)这个类定义了什么构造方法__init__接收外部传入的 title、author、price 三个参数并把它们绑定到 self 对应的属性上。这里的 self很多初学者理解不了我习惯用一句话解释self 指向的是“将来创建出来的那一个具体对象本身”。当你执行book1 Book(三体, 刘慈欣, 69)时Python 做两件事——先调用__new__创建一个空对象再调用__init__对这个空对象做初始化此时 self 就是这个新对象self.title title等于往对象身上写上“title”这个标签。调用类方法时并不需要显式传 selfPython 会自动把调用者 book1 传进去。所以book1.info()等价于Book.info(book1)这句话理解透后面看源码里出现instance.method()时就不会懵了。2.2 构造方法里藏着哪些细节关于__init__有几条实操经验是你需要提前知道的因为它们直接影响代码质量。第一__init__不是创建对象的方法它是初始化对象的方法。真正创建对象的是__new__日常开发中你基本不用重写__new__除非你在做单例模式或者不可变对象但知道这个区分很重要——当你在源码里看到__new__时不会误以为它是构造器。第二__init__允许你定义默认参数。比如图书的价格可以给一个默认值 0.0让相关字段不必每次传入。这是很实用的技巧像图书的出版年份、库存数量这类非必填信息都可以用默认参数处理。第三不要在__init__里定义可变默认值。比如def __init__(self, tags[])这是经典大坑。默认列表在函数定义时只创建一次所有没传 tags 的实例会共享同一个列表改一个全变。正确做法是写def __init__(self, tagsNone)内部再self.tags [] if tags is None else tags。我见过不少新手在后续调试时遇到“明明没动某个字段为什么所有对象的值都变了”的诡异问题十有八九就是可变默认参数惹的祸。把这一点写进你的自查清单能省掉很多排查时间。2.3 实例化多个对象后的内存隔离类的定义本身只是一份“设计图”只有执行实例化代码后才会产生实体对象。继续上面的 Book我们来创建两个对象book1 Book(三体, 刘慈欣, 69) book2 Book(活着, 余华, 39) book2.apply_discount(0.8) print(book1.info()) # 《三体》 by 刘慈欣定价 69 元 print(book2.info()) # 《活着》 by 余华定价 31.2 元这里值得注意book1 的价格是 69book2 经过打折变成 31.2两者互不干扰。原因在于实例属性是存储在各自对象自己的命名空间里的它们只是长得像内存地址完全不同。你可以用id(book1)和id(book2)验证两个地址不一样所以无论怎么修改 book2 自己的状态book1 都毫发无损。这种“对象间隔离”的特性是面向对象编程的基石。实际开发中你创建一个订单对象、一个用户对象、一个商品对象它们各自维护自己的状态各司其职模块间的耦合度会大幅降低。3. 实例方法、类方法与静态方法三种方法怎么选3.1 三种方法的定义与调用差异写完基础类之后day18马上会引入一个让很多初学者挠头的概念类里的方法怎么还有三种写法先看一个典型的对比示例class OrderProcessor: discount_rate 0.85 def __init__(self, order_id): self.order_id order_id self.amount 0 def apply_promotion(self, amount): # 实例方法第一个参数是 self需要实例才能调用 self.amount amount * self.discount_rate return self.amount classmethod def set_discount(cls, rate): # 类方法第一个参数是 cls可以通过类或实例调用 cls.discount_rate rate staticmethod def validate_amount(amount): # 静态方法既不接收 self 也不接收 cls相当于普通函数 return amount 0调用上的区别非常直观。实例方法必须创建对象后才能调用processor OrderProcessor(A001); processor.apply_promotion(100)。类方法可以用类直接调OrderProcessor.set_discount(0.9)也可以用实例调但无论哪种方式方法内部的 cls 都指向类本身。静态方法更简单OrderProcessor.validate_amount(100)就能用它放在类里主要是为了在代码组织上归类逻辑上与这个业务相关但不需要访问类或实例的任何数据。3.2 选型判断标准看要不要访问数据方法选型是面试和工作中都很常见的问题判断标准其实就是一个这个方法需不需要访问实例数据或类数据。如果方法内部使用了self.xxx也就是要看具体某个对象的状态那就必须是实例方法。比如计算订单金额、更新用户积分这些天然依赖单独对象的内部数据做不了类方法。如果方法内部不访问实例数据但需要修改或读取类级别的共享状态就用类方法。最经典的场景是修改类的公共配置项、维护全局计数器、提供带缓存功能的替代构造函数。用cls的好处是即使这个类将来被继承cls依然指向子类能保证配置修改作用在正确的类上。如果方法既不访问实例数据也不访问类数据只是逻辑上跟这个类相关就用静态方法。比如校验输入参数是否合法、做格式转换这类工具函数放在类里能提升代码的组织性又不绑定任何状态。我个人的习惯可以分享给你拿不准的时候优先写实例方法。因为实例方法最灵活既能访问实例数据又能访问类数据通过self.__class__如果一个方法将来被改成需要访问状态也不需要改签名。反过来如果一个方法确定不依赖任何对象状态又会被频繁调用改成静态方法或类方法可以让调用更轻量不用先造一个无意义对象。3.3 类方法的一个实用模式替代构造函数类方法中有一个非常实用的用法值得单独讲通过cls(...)返回一个新的实例。Python 标准库里大量使用这个模式比如datetime.fromtimestamp、dict.fromkeys。它的好处是让调用者不用关心对象的具体构造流程。举个例子你有一个User类正常初始化需要传入一堆详单字段但很多时候你是从一个字符串行文本或文件行记录里拿到数据的。这时候可以加一个类方法class User: def __init__(self, name, age, email): self.name name self.age age self.email email classmethod def from_line(cls, line): parts line.strip().split(,) return cls(parts[0], int(parts[1]), parts[2])这样读取文件时的代码就变得异常简洁user User.from_line(张三,25,zhangsanexample.com)。不用在外面写一大堆解析逻辑创建对象的细节全收进类内部后续解析规则变了只改一个地方。这个模式在 CLI 工具、数据导入脚本里特别常用你会在不少优秀开源项目的源码里看到类似的from_xxx类方法。理解它等于拿到了一个提升代码可维护性的利器。4. 属性管理的两把利器property与__slots__4.1 用property给字段安装“守门员”很多新手在类里写字段时喜欢直接self.price price觉得字段本来就是公开的随便读写就完事。但实际业务里字段往往是有约束的价格不能为负数、用户名不能为空、年龄必须在合理范围内。如果所有地方都靠调用方自觉检查总有漏网之鱼。Python 给出的解决方案是property。它可以把一个方法伪装成一个属性来访问从而在读写入口处统一加逻辑。看代码class Product: def __init__(self, name, price): self._name name self._price price property def price(self): return self._price price.setter def price(self, value): if value 0: raise ValueError(价格不能为负数) self._price value property def name(self): return self._name这里我故意把内部存储字段命名为_name和_price加下划线是一种约定表示“这些字段是类内部使用的请不要直接从外部访问”。对外暴露的price是一个 property 对象使用者照样写product.price 99来赋值但赋值会经过 setter 里的校验逻辑价格传负数直接抛异常。这就相当于给字段装了一个守门员。读的时候走property方法写的时候走 setter 方法外部代码的调用方式完全不变但安全性大大提升。更妙的是将来你还可以在 getter 里加缓存、在 setter 里触发事件通知都不需要修改调用方代码。4.2 __slots__真的能省内存吗Python 对象的实例属性默认用一个字典来存储这个字典提供了极大的灵活性——你可以在运行期间随便给实例添加新属性。但灵活的代价是内存占用偏高一个实例属性字典往往要消耗数百字节。当你要创建成千上万个对象时这开销就非常可观了。__slots__的作用是在类定义时声明一个固定属性列表告诉 Python 解释器这个类的实例只允许有这些属性。这样解释器就不再为每个实例生成属性字典而是改用更紧凑的内部结构存储。class Player: __slots__ (name, level, score) def __init__(self, name): self.name name self.level 1 self.score 0定义了__slots__后允许的属性被限制为 name、level、score。如果代码里写player.weapon sword会直接抛出 AttributeError 异常。从内存角度看实测下来大量实例场景下能省 30% 到 50% 的内存在游戏开发、数据分析、配置管理这类需要批量创建对象的场景中效果很明显。不过__slots__也有取舍。它会让类失去动态添加实例属性的能力同时会与 property 产生一些交互细节使用前需要想清楚。如果你的对象数量不大、对内存不敏感完全可以不写但如果你有“对象数量以百万计”的场景__slots__是必须掌握的优化手段。4.3 property与__slots__协同的坑把 property 和__slots__一起用是常见需求但里面藏着一个典型坑。如果类里写了__slots__ (name, price)同时又写了property def price(self)你会发现程序启动时直接报错ValueError: price in __slots__ conflicts with class variable。原因很简单__slots__里声明的每个属性名都会创建一个描述器而 property 本身也是一个描述器两个描述器争同一个名字解释器直接拒绝。解决办法是在__slots__里只声明内部存储字段而不是对外暴露的属性名。正确的写法是class Product: __slots__ (_name, _price) def __init__(self, name, price): self._name name self._price price property def price(self): return self._price price.setter def price(self, value): if value 0: raise ValueError(价格不能为负数) self._price value也就是说__slots__管理的是实际存储的属性名带下划线的内部字段property 是给外部看的接口名。这个坑在搜索引用时会让人摸不着头脑我在带练时几乎每次都会强调一次先想清楚哪些属性真正需要存储哪个属性只是访问接口。5. 继承、多态与混入类关系的进阶细节5.1 写继承前先问自己三个问题继承是面向对象绕不开的话题但我不建议一上来就写个“动物”基类当教学例教室里那种Animal - Dog的例子搬到真实业务里往往没多大用。实际开发中判断要不要用继承我通常先问三个问题。第一个问题子类和基类是不是严格的“is-a”关系图书是一种馆藏物品LibraryItem这个关系成立。如果只是“都有一些公共方法”这种弱关联优先考虑组合而不是继承。第二个问题子类是否真的需要复用基类的实现如果子类只是想要统一接口完全可以用一个抽象基类或者协议类来约束甚至直接鸭子类型解决不一定要借助继承来拿代码实现。第三个问题继承层级会不会超过三层多层继承会显著增加理解成本一旦继承链超过三层调试一个方法是哪个父类实现的就变得非常费劲。能两层的不要三层能用组合解决的尽量不堆层级。举个例子演示一个合理的继承结构class LibraryItem: def __init__(self, item_id, title): self.item_id item_id self.title title def describe(self): return f[{self.item_id}] {self.title} class Book(LibraryItem): def __init__(self, item_id, title, author): super().__init__(item_id, title) self.author author def describe(self): return super().describe() f by {self.author} class DVD(LibraryItem): def __init__(self, item_id, title, duration): super().__init__(item_id, title) self.duration duration def describe(self): return f{super().describe()}片长 {self.duration} 分钟这里 LibraryItem 提供了公共字段和基础 describe 逻辑Book 和 DVD 各自扩展自己的字段并重写 describe。这种继承是用得比较健康的。5.2 方法重写里必须调用super()吗这是继承学习中最容易出错的点。子类重写父类方法时到底要不要调用super().xxx()答案是看情况但绝大多数时候你需要。如果子类和父类的同名功能有延续关系子类想在父类实现的基础上追加逻辑那必须先调用super()。比如上面 Book 的describe如果不调用super().describe()就得把父类那行拼接逻辑完整复制一遍不仅冗余而且父类格式一旦修改子类就全部不同步了。如果子类是完全替换父类逻辑不打算保留任何父类意志那可以不调用。但这种情况更常见的处理方式是直接重写一个新方法名而不是同名覆盖——覆盖会破坏父类对外承诺的行为容易给后续维护埋雷。另一个高频坑是__init__里的super()漏调问题。子类定义了__init__后没有调用super().__init__()父类的字段就永远没有初始化访问父类那边定义的属性时就会得到 AttributeError。这个错误在初学继承时几乎人人都会踩一遍。排查办法是看报错堆栈属性错误出现的位置如果是在从父类继承的方法里那八成就是子类构造时没调用父类的初始化逻辑。5.3 多态的本质与MixIn组合思路多态这个概念在很多教程里讲得玄乎其实用一句话就能概括同一个方法名不同的对象执行时表现出不同的行为而调用方不需要关心对象的具体类型。Python 的鸭子类型让多态来得浑然天成。在检索系统里Book、DVD、Magazine 都实现了 describe 方法一个统一的函数可以遍历混合列表并逐一调用item.describe()完全不需要判断对象到底是谁。这个场景本质上依赖的是“接口的一致约定”而不是严格的继承关系所以 Python 开发者更偏好用 MixIn 思路来组织复用代码。所谓 MixIn是一种提供特定功能的混入类不参与主继承链专门给其它类提供额外能力。举个常见的例子你要给多个类增加 JSON 序列化能力class JsonMixin: def to_json(self): return json.dumps(self.__dict__, ensure_asciiFalse) class Book(LibraryItem, JsonMixin): pass class User: def __init__(self, name, age): self.name name self.age age这里 JsonMixin 不关心你的类里有什么字段它只提供to_json方法谁需要就混入谁。比起层层继承把所有能力塞进一个基类MixIn 的组合方式更灵活也不容易把无关类的耦合度拉高。等你将来阅读大型开源项目会发现 MixIn 是一种极其常见的代码组织手段。6. 魔术方法挑重点让自定义类更像原生类型6.1 最常用的几个魔术方法如果一个类里只有普通方法它的对象在语言层面其实不太好用。比如你用len(book)解释器会报错“对象不支持 len()”用for循环遍历也一样不行。魔术方法就是 Python 给类开的“协议后门”实现它们之后自定义对象就能使用语言内置的语法和函数。挑几个日常出现频率最高的介绍一下__str__定义str(obj)和print(obj)的行为返回值应该是给人看的友好描述。__repr__定义repr(obj)的行为返回值更多是给开发者看的应尽量精确、无歧义最好能直接用于重新创建对象。两者都实现时控制台显示优先用__repr__。__len__定义len(obj)的行为必须返回非负整数比如len(playlist)返回歌曲数量。__getitem__定义obj[key]的取值行为顺带还能让对象支持切片。__iter__定义迭代行为实现了它对象就能用于for循环。__contains__定义x in obj的判断逻辑实现之后成员判断会走你的自定义逻辑不再退化为遍历比较。6.2 实现一个可迭代的Playlist类只看概念容易记不住我们来写一个“歌单”类把上面提到的协议全部打通class Playlist: def __init__(self, songs): self._songs songs def __len__(self): return len(self._songs) def __getitem__(self, index): return self._songs[index] def __contains__(self, song): return song in self._songs def __str__(self): return fPlaylist({len(self._songs)} songs) def __repr__(self): return fPlaylist({self._songs!r})这个类一写完之前那些普通类做不到的玩法一下就解锁了pl Playlist([海阔天空, 光辉岁月, 真的爱你]) print(len(pl)) # 3 print(pl[1]) # 光辉岁月 print(海阔天空 in pl) # True for song in pl: print(song)为什么实现了__getitem__就能for循环因为 Python 的迭代协议规定当一个对象实现了__iter__时优先用__iter__否则如果实现了__getitem__解释器会按 0、1、2 这样的整数下标依次取值直到抛出 IndexError 为止。所以上面的例子即使没写__iter__也能遍历。这个设计非常巧妙它让“支持下标访问的对象天然支持迭代”大大降低了自定义容器类的实现门槛。如果用列表作为内部存储这个类的实现还算简单。真正要进阶的话你可以把_songs换成一个队列、一个数据库查询结果集甚至一个文件路径列表对外暴露的接口还是一模一样的内部逻辑怎么演化都不影响调用方——这正是面向对象封装的魅力。6.3 魔术方法不能乱用的边界魔术方法虽强但它的“魔法”集中在标准协议内有些地方要克制。第一__eq__如果实现通常建议和__hash__一起考虑。当你把一个对象塞进字典或集合时Python 依赖哈希值来定位如果你重写了相等判断但没有同步重写哈希方法会导致相等的对象有不同的哈希值出现“同一个逻辑对象无法被正确查找到”的诡异问题。第二__getattr__这类动态属性拦截方法能实现很多魔法但也极易把代码搞成“看似什么都能访问报错时却毫无线索”的状态。我的建议是新手阶段尽量少用__getattr__和__setattr__先用显式字段和 property 解决。等确实遇到类似“代理对象转发访问”的场景再考虑这些更底层的协议。第三不要把所有方法都实现一遍。有人喜欢给自己的类连__add__、__mul__一起写觉得自己写了一个“万能类型”。除非你确实需要数值运算或向量操作语义否则这是过度设计。Python 社区推崇“少即是多”实现一个协议不能满足真实需求时宁可不实现也别做出语义模糊的加法。7. day18的实战作业与常见翻车点7.1 综合演练写一个可用的Library类把前面所有知识点串起来最好的方式就是写一个综合项目。我给带练学员设计的作业是一个小型图书馆系统。要求包括有一个Book类带价格校验有一个Library类支持添加图书、按标题关键词搜索、统计馆藏量、遍历所有图书整体不允许使用任何第三方库纯粹用标准库和语言特性完成。参考实现骨架如下class Book: def __init__(self, title, author, price): self.title title self.author author self.set_price(price) def set_price(self, price): if price 0: raise ValueError(价格不能为负数) self._price price def get_price(self): return self._price def __str__(self): return f《{self.title}》{self.author} {self.get_price()}元 def __repr__(self): return self.__str__() class Library: def __init__(self): self._books [] def add_book(self, book): if any(b.title book.title and b.author book.author for b in self._books): raise ValueError(这本书已在馆) self._books.append(book) def search(self, keyword): return [book for book in self._books if keyword in book.title or keyword in book.author] def __len__(self): return len(self._books) def __iter__(self): return iter(self._books)这个作业题虽然小但练习价值很全Book 类实现了封装与数据校验字段Library 类实现了容器协议搜索逻辑测试了列表推导与条件判断整个系统没有任何一个多余的自由函数。做完这个可以说你对 day18 的核心知识已经建立了实操层面的肌肉记忆。用的时候可以这样验证lib Library() lib.add_book(Book(三体, 刘慈欣, 69)) lib.add_book(Book(活着, 余华, 39)) print(len(lib)) # 2 print([str(b) for b in lib.search(三)]) # [《三体》刘慈欣 69元]7.2 常见问题与排查实录我根据带练的反馈把大家最容易翻车的几个问题整理成了一张速查表你在调试时可以对照问题现象原因排查与修复调用方法时报缺少参数方法定义时第一个参数写成了self之外的名字或者忘记写self检查方法签名实例方法的第一个参数必须习惯命名为 self对两个内容相同的对象比较始终为 False没有实现__eq__默认走对象地址比较按业务语义实现__eq__有相等定义时考虑是否需要配套__hash__子类访问父类字段报 AttributeError子类__init__没有调用super().__init__()在子类构造方法开头补上super().__init__(...)给实例赋值新属性直接报错类定义了__slots__限制了属性集合检查__slots__是否忘记声明该属性或考虑是否需要该限制修改了一个对象其它对象也跟着变类属性被误当成实例属性使用或可变默认参数确认可变数据是否绑定在self上默认参数值使用不可变对象打印对象显示... object at 0x...类没有实现__str__或__repr__为类补上返回可读字符串的__str__这里单独展开说一个案例。有一次带练时有位同学对 Book 的价格做统一打折写的是Book.discount_rate 0.8然后所有 book 实例的__init__里都用self.price price * Book.discount_rate。表面看没问题但某天他想单独给某本书做不同的折扣直接给 book1 设book1.discount_rate 0.5结果发现 book1 并不会按 0.5 计算。原因在于他设置的 discount_rate 变成了 book1 实例的新属性并没有改变 Book 类上的那个类属性而构造方法里读取的是类属性Book.discount_rate根本没有读到实例上的新属性。这个例子特别适合说明类属性和实例属性的区别类属性存在类对象自己的命名空间里通过实例访问时Python 先找实例属性找不到再回头找类属性但一旦通过实例给同名属性赋值反而是在实例上创建了遮挡类属性的新属性。理解这条查找链路很多属性相关的坑都能直接避开。7.3 避坑心得这些细节帮我省了大量时间最后再聊几句我的个人体会。学面向对象最容易犯的错误是“光看不写”。很多人看教程觉得类、继承、property 都懂了一上手却发现连对象怎么互相调用都理不清楚。我自己的经验是每学一个新知识点立刻在一个最小例子里用一遍。比如看到__slots__就写一个 10 万条对象的类做一次内存对比看到类方法就写一个from_csv的构造函数。这种“看到什么就立刻实验什么”的习惯能让知识的留存率提高非常多。另外遇到报错不要急着改代码先看报错信息指向的代码行再往上一层层看调用栈。Python 的异常堆栈信息已经写得很直白80% 的问题能靠读懂报错字段解决。真正难查的往往是那些静默问题——比如上面提到的可变默认参数程序不报错只是行为悄悄偏离预期。对这种问题最好的办法其实是提前防御凡是函数或方法定义里的默认参数坚决不用可变的列表和字典凡是类属性问自己一句“它真的是所有实例共享的吗”。多问自己这两句大约能躲掉初学者一半以上的隐蔽 bug。day18 的内容说多不多说少不少但它是你从“写脚本的人”变成“写程序的人”的重要拐点。类的封装思想一旦建立后面再去看模块化设计、设计模式、框架源码都会有一种“原来是这么回事”的通透感。你把这篇文章里提到的方法和示例都亲手敲一遍敲完再自己动手改几个小需求这一天的学习就算真正落地了。