企业官网建设流程全解析

1. 这不是又一本“照着抄”的Python面向对象教程

你点开这个标题，大概率是刚学完变量、循环、函数，正对着类、实例、继承这些词发懵；也可能是写过几个脚本，但一看到别人代码里满屏的self、__init__、@property就下意识想跳过；甚至可能是从 Java 或 C# 转过来的，发现 Python 的“面向对象”怎么看起来这么“随意”，连个publicprivate都没有，心里直犯嘀咕——这玩意儿到底靠不靠谱？

我带过不下200个零基础转行的学员，也给十多家中小企业的内部开发团队做过 Python 基础加固培训。最常听到的一句话是：“老师，我知道类是啥，也能照着例子敲出来，可一让我自己设计一个‘用户管理模块’或者‘订单处理系统’，我就卡在第一步：该建几个类？每个类里放哪些方法？属性该不该暴露？什么时候用继承，什么时候用组合？”

这恰恰说明，问题从来不在语法本身，而在于面向对象不是一套语法糖，而是一种建模思维。Python 的面向对象之所以被称作“超详版”需求，是因为它既不像 Java 那样用强约束逼你思考封装边界，也不像 JavaScript 那样靠原型链让人绕晕——它把选择权交给你，但代价是你得真正理解“为什么这样设计”。

所以这篇内容，不讲“类怎么定义”，而是带你从一个真实场景出发：我们手头有个 CSV 文件，存着几百条销售记录（日期、商品名、销量、单价、区域），老板要你做三件事：

1. 快速统计每个区域的总销售额；
2. 找出单日销量破千的商品；
3. 把结果导出成带格式的 Excel，并自动邮件发给财务。

你会怎么写？如果只用函数+字典，代码很快会变成一长串for套if再套sum()，改一个需求就得通篇找变量名；但如果用面向对象的方式，你会自然地拆解出SaleRecord（单条记录）、SalesReport（报表生成器）、EmailNotifier（通知器）三个角色，每个角色只关心自己的事，改统计逻辑不影响发邮件，换 Excel 库也不动数据模型。

这就是面向对象的底层价值：让代码像现实世界一样有边界、有职责、有协作关系。后面所有细节——__init__干什么、@staticmethod和@classmethod区别在哪、为什么__str__比print()更重要、isinstance()和hasattr()在什么场景下比type()更安全——全是为了支撑这个目标服务的。你不需要死记硬背“多态的三大要素”，但必须清楚：当你要替换一个支付模块（微信→支付宝→银联），如果所有调用方都只认pay()这个方法名，而不关心背后是哪个类，你的系统才真正具备扩展性。

这篇文章就是为你写的：不堆砌概念，不罗列语法，而是用你每天都会遇到的真实编码困境，倒推每一个面向对象特性的存在理由。它适合两类人：一是刚写完第一个def hello():的新手，需要知道“下一步该往哪走”；二是写了半年脚本却总觉得代码“越写越累”的进阶者，需要一次系统性的思维校准。如果你只想查某个装饰器怎么写，直接 Ctrl+F；但如果你想搞懂“为什么非得这么写”，请从头读起——因为真正的“超详”，不在代码行数，而在每一行背后的决策逻辑。

2. 整体设计思路：从“能跑通”到“可维护”的三层跃迁

很多初学者对面向对象的理解停留在“把函数塞进类里”这个层面，比如把calculate_total()函数改成class Calculator:里的一个方法，就以为完成了面向对象改造。这就像把自行车零件全拆下来，再按原样装回车架上——结构没变，只是换了容器。真正的面向对象设计，是一次认知重构，它要求你回答三个递进式问题：这个东西“是什么”？它“能做什么”？它“和谁协作”？我们以销售数据处理为例，拆解这三层跃迁的具体路径。

2.1 第一层：识别实体与职责（What & Can Do）

先抛开代码，拿张纸画出业务中的核心名词：销售记录、区域、商品、报表、邮件。这些就是潜在的“类”。但并非所有名词都值得建类——关键看它有没有独立的状态（属性）和行为（方法）。比如“区域”如果只是个字符串'华东'，那它就是个普通变量；但如果它需要计算该区域历史平均增长率、维护下属城市列表、判断是否属于重点扶持区域，那它就必须是一个类。

我们聚焦“销售记录”：每条记录有日期、商品名、销量、单价、区域。这些是它的状态。它能做什么？可以计算单条金额（销量×单价），可以判断是否达标（销量>1000），可以格式化为字符串用于日志。这些是它的行为。于是SaleRecord类的骨架就清晰了：

class SaleRecord: def __init__(self, date, product, quantity, unit_price, region): self.date = date self.product = product self.quantity = quantity self.unit_price = unit_price self.region = region def total_amount(self): return self.quantity * self.unit_price def is_high_volume(self): return self.quantity > 1000 def __str__(self): return f"{self.date} {self.product}: {self.quantity}件 × ¥{self.unit_price}"

注意这里的关键设计点：__init__不是“初始化函数”，而是定义这个实体存在的必要条件。你不能创建一个没有quantity的销售记录，所以它必须是__init__的参数。而total_amount()方法里直接用self.quantity * self.unit_price，而不是传参进来，是因为金额是这条记录固有的衍生属性，它的计算逻辑永远绑定在这个实体上——这是封装的起点：把数据和操作数据的逻辑捆在一起。

2.2 第二层：定义协作关系（How to Collaborate）

单个类只是积木，系统由积木的连接方式决定。回到老板的三个需求，SaleRecord自己解决不了“统计区域总销售额”，因为它不知道其他记录的存在。这就需要第二个类：SalesReport，它的职责不是存储数据，而是协调多个SaleRecord实例完成聚合任务。

SalesReport不应该自己去读 CSV 文件（那是 IO 的事），也不应该直接修改SaleRecord的属性（破坏封装），它只做一件事：接收一个SaleRecord列表，提供get_region_sales()这样的方法。实现时，它用defaultdict按区域分组，再对每组调用record.total_amount()——看，它完全依赖SaleRecord暴露的total_amount()方法，而不关心这个方法内部是乘法还是查数据库。这种“只认接口，不认实现”的协作，就是多态的雏形。

更进一步，当需求变成“导出 Excel”，SalesReport也不该自己写 openpyxl 的代码。它应该有一个export_to_excel()方法，但这个方法内部调用的是另一个专门负责文件输出的类，比如ExcelExporter。这样，未来老板说“改成 PDF”，你只需写个PDFExporter，然后在SalesReport里换一行注入，其他代码零改动。这种“把变化点隔离到独立类中”的设计，就是依赖倒置原则的实践——高层模块（报表）不依赖低层模块（Excel 导出），二者都依赖抽象（一个Exporter接口）。

2.3 第三层：应对变化与扩展（Why This Design）

面向对象的终极考验，是当需求变更时，你的代码是否“牵一发而动全身”。假设老板新增需求：“支持按促销活动维度统计”。如果原始设计是把所有逻辑硬编码在SalesReport.get_region_sales()里，那你得重写整个方法，还可能误伤区域统计逻辑。但若你提前设计了策略模式：

from abc import ABC, abstractmethod class SalesAggregator(ABC): @abstractmethod def aggregate(self, records: list) -> dict: pass class RegionAggregator(SalesAggregator): def aggregate(self, records): # 按区域聚合逻辑 pass class CampaignAggregator(SalesAggregator): def aggregate(self, records): # 按活动聚合逻辑 pass class SalesReport: def __init__(self, aggregator: SalesAggregator): self.aggregator = aggregator # 依赖注入 def generate_report(self, records): return self.aggregator.aggregate(records)

现在，新增活动统计，只需写一个新的CampaignAggregator类，然后report = SalesReport(CampaignAggregator())——零修改现有代码。这种设计不是为了炫技，而是因为我在实际项目中见过太多次：一个“临时加的需求”，因为架构没预留扩展点，最后演变成推翻重写。Python 的灵活性让你可以晚点做设计，但“超详版”的意义，就是帮你把那些“晚点做”的坑，在第一次写类时就避开。

提示：不要一上来就追求完美设计。我的建议是“两步走”：先快速用最直白的类实现核心功能（哪怕暂时把 IO 逻辑塞进类里），跑通流程；第二步再审视：哪些部分重复了？哪些逻辑和数据耦合太紧？哪些地方改一个需求要动五六个文件？这时再引入继承、组合、抽象基类，效果立竿见影。

3. 核心细节解析：那些被忽略的“为什么”与实操陷阱

Python 的面向对象语法看似简单，但每个符号背后都有明确的设计意图。初学者常把self当作语法负担，把__开头的方法当成“黑魔法”，把@property当作炫技工具——结果是代码越写越像 Java 的拙劣翻译。这一节，我们撕开语法表象，直击每个特性的存在理由，并给出真实场景下的避坑指南。

3.1self：不是关键字，而是契约

self不是 Python 关键字，你甚至可以用this或me替代（虽然强烈不建议）。它的本质是实例方法的第一个隐式参数，指向调用该方法的对象本身。当你写record.total_amount()，Python 解释器实际执行的是SaleRecord.total_amount(record)。这个设计不是为了增加打字量，而是为了明确“这个方法操作的是谁的数据”。

常见误区是试图在__init__外部访问未初始化的属性：

class BadExample: def __init__(self, name): # 忘记初始化 age 属性 self.name = name def introduce(self): return f"I am {self.name}, {self.age} years old" # AttributeError! obj = BadExample("Alice") obj.introduce() # 崩溃！

问题根源在于self.age在__init__中根本没被赋值。正确做法是在__init__中显式初始化所有预期属性，哪怕给默认值：

class GoodExample: def __init__(self, name, age=None): self.name = name self.age = age # 明确声明，避免 AttributeError

更进一步，用dataclasses或__slots__强制约束属性集，能提前暴露这类错误。__slots__ = ['name', 'age']会让obj.height = 170直接报错，而不是静默创建新属性——这在大型项目中能省下无数调试时间。

3.2__init__vs__new__：构造器的分工

__init__负责“初始化”，即给已创建的对象设置初始状态；__new__负责“创建”，即分配内存并返回新实例。99% 的场景只需__init__，但当你需要控制实例创建过程时（如单例模式、不可变对象），__new__就不可或缺。

单例模式的经典实现：

class Singleton: _instance = None def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) # 真正创建实例 return cls._instance # 总是返回同一个实例 def __init__(self): # 注意：__init__ 每次都会被调用！所以需加标记避免重复初始化 if not hasattr(self, '_initialized'): self.data = [] self._initialized = True

这里的关键是：__new__返回的是实例，__init__是对这个实例的修饰。如果__new__返回的不是当前类的实例（比如返回int(5)），__init__根本不会被调用。这个机制让 Python 可以实现int('123')这种“类型转换”——int.__new__直接返回一个整数对象，跳过__init__。

3.3@property：用方法伪装的属性

@property的核心价值是在不破坏接口的前提下，为属性访问添加逻辑。比如SaleRecord的total_amount应该是只读的（销量和单价变了，金额自动更新），但直接暴露total_amount属性会导致外部篡改：

record = SaleRecord("2024-01-01", "iPhone", 10, 6000, "华东") record.total_amount = 99999 # 危险！金额被手动改了

用@property就能解决：

class SaleRecord: def __init__(self, date, product, quantity, unit_price, region): self.date = date self.product = product self._quantity = quantity # 用下划线约定私有 self._unit_price = unit_price self.region = region @property def quantity(self): return self._quantity @quantity.setter def quantity(self, value): if value < 0: raise ValueError("销量不能为负数") self._quantity = value @property def total_amount(self): return self._quantity * self._unit_price # 只读，无 setter

现在record.total_amount = 99999会报AttributeError，而record.quantity = -5会触发验证。@property让你把“字段级验证”和“计算逻辑”无缝集成到属性访问中，使用者感觉就是在读一个普通属性，而你获得了完全的控制权。

3.4 继承与super()：不只是代码复用

继承常被误解为“为了少写代码”，但它真正的意义是建立 is-a 关系，并支持运行时多态。比如VIPCustomer是Customer的一种，所以VIPCustomer可以继承Customer，并重写get_discount()方法。但重写时，如何调用父类逻辑？用super()，而不是Customer.get_discount(self)。

为什么？因为super()支持方法解析顺序（MRO），在多重继承中能正确找到下一个类。看这个经典例子：

class A: def method(self): print("A.method") class B(A): def method(self): print("B.method") super().method() # 调用 A.method class C(A): def method(self): print("C.method") super().method() # 调用 A.method class D(B, C): def method(self): print("D.method") super().method() # 关键：按 MRO 调用 B.method，然后 C.method，最后 A.method print(D.__mro__) # (<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>) D().method() # 输出： # D.method # B.method # C.method # A.method

如果D.method()里写B.method(self)和C.method(self)，会重复调用A.method，且无法保证顺序。super()让 Python 自动按 MRO 链推进，这是构建可维护继承体系的基础。记住：在重写方法时，除非有绝对把握，否则一律用super()调用父类逻辑。

3.5 特殊方法（Magic Methods）：让自定义类融入 Python 生态

__str__、__len__、__eq__这些方法，是 Python 为你定制的“接入点”。它们不改变你的类逻辑，但决定了你的类如何与 Python 内置函数和运算符交互。

• __str__让print(obj)输出可读字符串，__repr__让repr(obj)输出开发者友好的调试信息（应尽可能包含创建对象所需的信息，如SaleRecord('2024-01-01', 'iPhone', 10, 6000, '华东')）。
• __len__让len(obj)可用，比如SalesReport的__len__可以返回记录总数。
• __eq__让==比较有意义：record1 == record2应该比较关键字段（如日期+商品名），而不是内存地址。

最易被忽视的是__bool__：它决定if obj:的真假值。默认情况下，空容器为False，非空为True，但自定义类默认总是True。如果你的SalesReport为空时希望if report:返回False，就必须实现：

def __bool__(self): return len(self.records) > 0 # 有记录才为 True

这些方法不是锦上添花，而是让你的类真正成为 Python “一等公民”的必经之路。没有__eq__，你就无法用assert record in report_records；没有__bool__，你就得写if len(report.records) > 0:而不是简洁的if report:。

4. 实操过程：从零构建一个可落地的销售分析系统

理论终需落地。现在，我们用前面所有设计原则，完整实现一个最小可行的销售分析系统。它不追求功能大而全，但每个环节都体现面向对象的核心思想：职责分离、接口抽象、可测试性。所有代码均可直接复制运行（需安装pandas和openpyxl）。

4.1 步骤一：定义核心数据实体SaleRecord

首先，SaleRecord必须健壮。它要能从 CSV 行解析数据，要能验证输入合法性，要能计算衍生值：

import re from datetime import datetime from typing import Optional class SaleRecord: def __init__(self, date: str, product: str, quantity: int, unit_price: float, region: str): # 输入验证：日期格式、数量非负、价格正数、区域非空 if not re.match(r'^\d{4}-\d{2}-\d{2}$', date): raise ValueError(f"日期格式错误: {date}") try: self.date = datetime.strptime(date, '%Y-%m-%d').date() except ValueError as e: raise ValueError(f"无效日期: {date}") from e if not isinstance(quantity, int) or quantity < 0: raise ValueError(f"销量必须为非负整数: {quantity}") if unit_price <= 0: raise ValueError(f"单价必须为正数: {unit_price}") if not product.strip() or not region.strip(): raise ValueError("商品名和区域不能为空") self.date = datetime.strptime(date, '%Y-%m-%d').date() self.product = product.strip() self.quantity = quantity self.unit_price = round(unit_price, 2) # 保留两位小数 self.region = region.strip() @property def total_amount(self) -> float: """只读属性：单条记录总金额""" return round(self.quantity * self.unit_price, 2) @property def is_high_volume(self) -> bool: """只读属性：是否高销量""" return self.quantity >= 1000 def __str__(self) -> str: return f"[{self.date}] {self.product} ({self.region}): {self.quantity}件 × ¥{self.unit_price} = ¥{self.total_amount}" def __repr__(self) -> str: return (f"SaleRecord(date='{self.date}', product='{self.product}', " f"quantity={self.quantity}, unit_price={self.unit_price}, region='{self.region}')") def __eq__(self, other) -> bool: """基于关键字段比较：日期、商品、销量、单价、区域""" if not isinstance(other, SaleRecord): return False return (self.date == other.date and self.product == other.product and self.quantity == other.quantity and self.unit_price == other.unit_price and self.region == other.region)

实操心得：验证逻辑放在__init__里，确保对象一旦创建就处于有效状态。@property让total_amount和is_high_volume成为“活”的属性，数据变，结果自动更新。__eq__的实现避免了后续用list.index()时因内存地址不同而找不到对象的问题。

4.2 步骤二：构建数据加载器DataLoader

SaleRecord只管单条数据，加载 CSV 是另一件事。DataLoader职责明确：读取文件，解析为SaleRecord列表，处理异常：

import csv from pathlib import Path from typing import List class DataLoader: def __init__(self, file_path: str): self.file_path = Path(file_path) if not self.file_path.exists(): raise FileNotFoundError(f"文件不存在: {file_path}") def load_records(self) -> List[SaleRecord]: """加载所有销售记录，跳过错误行并记录警告""" records = [] warnings = [] with open(self.file_path, 'r', encoding='utf-8') as f: reader = csv.DictReader(f) for i, row in enumerate(reader, start=2): # 从第2行开始（跳过header） try: record = SaleRecord( date=row['date'].strip(), product=row['product'].strip(), quantity=int(row['quantity'].strip()), unit_price=float(row['unit_price'].strip()), region=row['region'].strip() ) records.append(record) except (ValueError, KeyError) as e: warnings.append(f"第{i}行数据错误: {e}") if warnings: print("数据加载警告：") for w in warnings: print(f" - {w}") return records

注意：DataLoader不持有records，它只提供load_records()方法。这符合“单一职责”——它只负责加载，不负责存储或处理。后续如果要支持 JSON 或数据库，只需新增JSONDataLoader类，SalesReport完全不用改。

4.3 步骤三：实现报表生成器SalesReport

SalesReport是核心协调者。它接收SaleRecord列表，提供多种聚合方法，并通过策略模式支持扩展：

from collections import defaultdict, Counter from typing import Dict, List, Any, Callable from abc import ABC, abstractmethod class AggregationStrategy(ABC): """聚合策略抽象基类""" @abstractmethod def aggregate(self, records: List[SaleRecord]) -> Dict[Any, float]: pass class RegionAggregator(AggregationStrategy): def aggregate(self, records: List[SaleRecord]) -> Dict[str, float]: result = defaultdict(float) for r in records: result[r.region] += r.total_amount return dict(result) class ProductAggregator(AggregationStrategy): def aggregate(self, records: List[SaleRecord]) -> Dict[str, float]: result = defaultdict(float) for r in records: result[r.product] += r.total_amount return dict(result) class SalesReport: def __init__(self, records: List[SaleRecord], aggregator: AggregationStrategy = None): self.records = records self.aggregator = aggregator or RegionAggregator() # 默认按区域 def get_region_sales(self) -> Dict[str, float]: """获取区域销售额（兼容旧接口）""" return self.aggregator.aggregate(self.records) def get_top_products(self, top_n: int = 5) -> List[tuple]: """获取销量最高的前N个商品""" counter = Counter([r.product for r in self.records]) return counter.most_common(top_n) def get_high_volume_days(self) -> List[str]: """获取有高销量记录的日期""" return sorted(set(str(r.date) for r in self.records if r.is_high_volume)) def __len__(self) -> int: return len(self.records) def __bool__(self) -> bool: return len(self.records) > 0

这里的关键是aggregator参数。它让SalesReport与具体聚合逻辑解耦。测试时，你可以传入一个模拟的MockAggregator，无需真实数据；生产时，切换ProductAggregator只需改一行构造参数。

4.4 步骤四：添加导出器ExcelExporter

导出逻辑独立成类，遵循“依赖倒置”：

from openpyxl import Workbook from openpyxl.styles import Font, PatternFill from pathlib import Path class ExcelExporter: def __init__(self, output_path: str): self.output_path = Path(output_path) def export(self, report: SalesReport) -> None: wb = Workbook() ws = wb.active ws.title = "销售报表" # 表头 headers = ["日期", "商品", "销量", "单价", "区域", "总金额"] for col, header in enumerate(headers, 1): cell = ws.cell(row=1, column=col, value=header) cell.font = Font(bold=True) cell.fill = PatternFill(start_color="CCCCCC", end_color="CCCCCC", fill_type="solid") # 数据行 for row_idx, record in enumerate(report.records, 2): ws.cell(row=row_idx, column=1, value=str(record.date)) ws.cell(row=row_idx, column=2, value=record.product) ws.cell(row=row_idx, column=3, value=record.quantity) ws.cell(row=row_idx, column=4, value=record.unit_price) ws.cell(row=row_idx, column=5, value=record.region) ws.cell(row=row_idx, column=6, value=record.total_amount) wb.save(self.output_path) print(f"报表已导出至: {self.output_path}") # 使用示例 if __name__ == "__main__": # 1. 加载数据 loader = DataLoader("sales_data.csv") records = loader.load_records() # 2. 创建报表（默认按区域聚合） report = SalesReport(records) # 3. 查看结果 print("=== 区域销售额 ===") for region, amount in report.get_region_sales().items(): print(f"{region}: ¥{amount:.2f}") print(f"\n=== 高销量商品 Top 3 ===") for product, count in report.get_top_products(3): print(f"{product}: {count}次") # 4. 导出 Excel exporter = ExcelExporter("sales_report.xlsx") exporter.export(report)

这个系统现在具备了：

• 可测试性：每个类职责单一，可独立单元测试（如test_SaleRecord_init_validates_input）；
• 可扩展性：新增PDFExporter或EmailNotifier，只需实现对应接口，SalesReport零修改；
• 可维护性：修改区域统计逻辑，只动RegionAggregator；修复 CSV 解析 bug，只动DataLoader。

注意：实际项目中，SalesReport的__init__应接受DataLoader实例而非records列表，实现更彻底的依赖注入。此处为简化演示，但原理一致。

5. 常见问题与排查技巧实录：那些只有踩过才知道的坑

面向对象的学习曲线，往往不是卡在语法，而是卡在“为什么我的代码不按预期工作”。以下是我在教学和代码审查中，高频出现的 7 个典型问题，附带真实排查过程和独家技巧。

5.1 问题一：AttributeError: 'XXX' object has no attribute 'yyy'—— 属性访问失败

现象：record.total_amount报错，但明明SaleRecord类里定义了@property。
排查路径：

1. 检查record是否真的是SaleRecord实例：print(type(record))。常见原因是record是None（比如DataLoader.load_records()因异常返回空列表，你忘了检查就直接for r in []，r从未被赋值）。
2. 检查__init__是否成功执行：在__init__开头加print("init called")，确认构造函数被调用。
3. 检查属性名拼写：total_amountvstotal_ammount，Python 不会提示拼写错误，只会报AttributeError。
   独家技巧：用dir(record)查看对象所有可用属性和方法，快速定位缺失项。如果total_amount不在列表中，说明@property未生效（可能__init__未执行，或类定义有语法错误）。

5.2 问题二：TypeError: unhashable type: 'dict'—— 字典作为字典键失败

现象：region_dict = {record.region: ...}报错，record.region是字符串，为何报错？
真相：record.region其实是None（因为__init__中row['region']为空，strip()后成空字符串，但验证逻辑漏掉了if not region.strip()）。None是不可哈希的。
排查技巧：在__init__的验证后，加一行assert isinstance(self.region, str) and self.region，让错误在源头暴露，而不是在下游使用时报奇怪的unhashable错误。

5.3 问题三：__eq__不生效，in操作符返回False

现象：record in record_list总是False，即使record和列表中对象内容完全相同。
原因：record_list中的对象是SaleRecord，但record是另一个类（比如你误用了dict或namedtuple）。__eq__只在同类比较时调用。
验证方法：print(record.__class__, record_list[0].__class__)。
解决方案：确保所有对象都是同一类实例。用isinstance(record, SaleRecord)断言。

5.4 问题四：super()调用父类方法，但父类方法没执行

现象：VIPCustomer.get_discount()中super().get_discount()没打印预期日志。
原因：父类Customer.get_discount()是@staticmethod或@classmethod，而super()在实例方法中调用时，会尝试绑定self，导致签名不匹配。
修复：统一方法类型。如果父类方法是@staticmethod，子类重写也用@staticmethod；或者全部改为实例方法。

5.5 问题五：@property的 setter 不触发

现象：record.quantity = 100没触发@quantity.setter中的验证逻辑。
原因：@property和@xxx.setter必须同名，且setter必须在property之后定义。如果顺序颠倒，setter会被忽略。
检查清单：

• @property装饰器在前；
• @xxx.setter装饰器在后，且xxx与@property下方法名完全一致；
• setter方法必须有且仅有一个参数（除self外），即新值。

5.6 问题六：多重继承中super()调用顺序混乱

现象：class D(B, C)中，super().method()调用了C.method()，但你期望先B。
根源：MRO 顺序由class D(B, C)的括号内顺序决定，D.__mro__显示(D, B, C, A, object)，所以super()在D中调用，下一个确实是B。
调试命令：print(D.__mro__)是必查项。如果顺序不对，调整类定义中的继承顺序：class D(C, B)。

5.7 问题七：__str__和__repr__输出混乱，日志难以阅读

现象：print(record)输出一堆内存地址，logging.info(record)打印"<__main__.SaleRecord object at 0x...>"。
原因：__str__或__repr__方法有异常（如访问了未初始化的属性），Python 会静默降级到默认实现。
排查技巧：单独调用print(record.__str__())和print(record.__repr__())，看哪个报错。
最佳实践：__repr__应尽可能返回可执行的创建语句，方便调试；__str__返回人类可读的摘要。两者都应做防御性编程：try/except包裹可能出错的属性访问。