兔子313在C++里写了几年游戏引擎核心，后来又用Python做AI训练和数据处理，这两种语言来回切换时，最让我觉得“既熟悉又陌生”的就是Class继承。语法上看起来都是“子类 extends 父类”，但真正用起来，完全是两套思维模型。你拿C++那套去写Python，能跑但别扭；拿Python那套去写C++，编译期直接教你做人。
这篇文章我结合自己的实际项目经验，把Python和C++在类继承方面的差异掰开揉碎了讲一遍。不会只停留在“语法不同”这种表面，而是深入到内存布局、方法查找、多继承策略、构造析构机制这些底层逻辑，再配上大量可运行的代码和踩坑记录。无论你是C++转Python、Python转C++，还是平常只用其中一门想补全另一门的知识盲区，这篇都能给你实在的参考。
1. 两种继承的底层哲学：一个管内存，一个管名字
1.1 C++ 继承在内存里真正“复制”了基类
C++的继承本质上是内存布局的复用和扩展。我这么说可能有点抽象，但你看代码就明白了。
cpp复制class Animal {
public:
Animal(const std::string& name) : name_(name) {}
virtual void speak() const {
std::cout << name_ << " makes a sound" << std::endl;
}
protected:
std::string name_;
};
class Dog : public Animal {
public:
Dog(const std::string& name) : Animal(name) {}
void speak() const override {
std::cout << name_ << " barks" << std::endl;
}
};
在C++里，当你声明 Dog dog("旺财") 时，内存中 dog 这个对象从低地址到高地址依次排列着 Animal 的子对象和 Dog 自己的成员。也就是说，Animal 的 name_ 成员变量在内存中是实实在在存在的一份数据副本。
这一点在实际工程中影响非常大。我早期写一个消息系统时，基类里放了一个 std::vector 作为缓冲区，派生类不断地往这个缓冲区里塞数据。因为继承就是内存子对象的嵌套，sizeof(Derived) 直接等于 sizeof(Base) + 各自成员大小，我一开始算错了内存上限，导致缓冲区在栈上越界。后来我深刻记住了：C++的继承不是“逻辑上的属于”关系，而是“物理上的包含”关系。
而且C++的虚函数是靠虚函数表（vtable）实现的。每个有虚函数的类，在编译期会生成一张虚函数表，表格里保存的是函数指针。类对象的内存里会多一个虚函数表指针（vptr）指向这张表。派生类重写基类的虚函数时，实际上是在自己的虚函数表里，用新的函数地址覆盖了基类函数地址对应的槽位。
我之前排查过一个奇怪的bug：基类和派生类声明了同名同参数的同名函数，但基类没加 virtual，派生类加了。调用时表现出的行为完全不像“多态”，我一度以为是编译器优化的问题。实际上就是虚函数表里压根没有这个函数的槽位，普通的成员函数调用在编译期就确定地址了。
1.2 Python 继承只是多了一条“查方法”的路
Python的继承和C++完全不一样。Python的类对象本质上是 type 类型的实例，类之间的关系靠的是 __bases__ 元组和一个方法解析顺序（MRO）。当你调用一个对象的某个方法时，Python不是直接去“找内存里的函数指针”，而是沿着MRO去各个类对象的 __dict__ 里查这个名字。
python复制class Animal:
def __init__(self, name: str):
self.name = name
def speak(self) -> None:
print(f"{self.name} makes a sound")
class Dog(Animal):
def __init__(self, name: str):
super().__init__(name)
def speak(self) -> None:
print(f"{self.name} barks")
在这个例子里，当你执行 dog.speak() 时，Python先看 Dog.__dict__ 里有没有 speak，有就直接用。如果没有，就顺着MRO往后找，在 Animal 里找到了就用。实例对象的 self.name 则存放在每个实例自己的 __dict__ 里。
这种设计带来的一个关键差别是：内存里并不存在一个物理上的 Animal 子对象。Dog实例就是一个普通的字典（加了一些特殊属性），它“继承”来的 name 属性，只是因为在 Animal.__init__ 里 self.name = name 时才被创建出来。
所以Python的继承更像一个“属性查找的顺序表”，而不是“内存布局的复制”。这个差异直接决定了：
- C++中你无法在运行时给对象增加新的成员变量，Python可以；
- C++中一个空类继承一个基类，
sizeof至少是1，内存布局在编译期就固定了，Python的对象大小则取决于实例字典里放了多少内容。
我见过很多从C++转Python的人容易犯一个毛病：写Python类时，先定义一个空类，再手动 obj.xxx = 10 去补充属性。这在Python里完全合法，因为它压根不限制实例可以有哪些属性。但在C++里，你必须在类体里把所有成员都声明好，运行时没有任何办法给对象“加塞”一个新成员。这就是这两种语言在继承哲学上最本质的分歧。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 语法层面：声明、构造、析构的差异化体验
2.1 类声明与对象创建：C++ 的户口本 vs Python 的黑板
C++中类和对象是“分离”的。类定义通常写在头文件里，声明的成员函数实现可以放在 .cpp 文件里。这种分离带来了编译期的强约束：你在写一个类的时候，必须告诉编译器这个类长什么样、有哪些成员、哪些函数是虚函数。这就相当于给对象上了一本户口本，所有信息在编译期就要登记清楚。
cpp复制// animal.h
#ifndef ANIMAL_H
#define ANIMAL_H
#include <string>
class Animal {
public:
Animal(const std::string& name);
virtual ~Animal();
virtual void speak() const;
protected:
std::string name_;
};
#endif
cpp复制// animal.cpp
#include "animal.h"
#include <iostream>
Animal::Animal(const std::string& name) : name_(name) {}
Animal::~Animal() = default;
void Animal::speak() const {
std::cout << name_ << " makes a sound" << std::endl;
}
这种分离式写法在大型项目里是必须的，能显著缩短编译时间，各个模块可以并行编译。但在小项目里写起来确实繁琐。我记得刚用C++写服务器的时候，最烦的就是每次新增一个类，头文件和源文件来回切换，改个成员函数签名还得手动把两边的声明和定义都同步改掉。后来用Clion的自动重构功能才好了一些。
而Python的类定义是一次性写在同一个模块里的，没有头文件和实现文件的区别。你打开一个 .py 文件，就能看到这个类的全部面貌。这相当于直接在黑板上写定义，写完了就能用，不需要提前告诉编译器“我要定义一个类”。
python复制class Animal:
def __init__(self, name: str):
self.name = name
def speak(self) -> None:
print(f"{self.name} makes a sound")
Python这种设计的好处是迭代速度极快，改完直接运行。坏处是没有编译期检查，一旦在类里写错一个 __init__ 的变量名，运行到那行才报错。我在写脚本处理数据时遇到过很多次 AttributeError: 'Animal' object has no attribute 'xxx'，就是因为 __init__ 里拼错了变量名，而用到这个属性的地方却写的是另一个名字。
2.2 构造与析构：C++ 必须手动搭桥，Python 留给你自己
构造与析构是C++和Python继承差异中特别值得展开的部分，因为这直接关系到内存安全和对象生命周期。
C++中，派生类的构造函数默认会调用基类的默认构造函数。如果基类没有默认构造函数，你必须在派生类的初始化列表里显式传入参数：
cpp复制class Dog : public Animal {
public:
Dog(const std::string& name) : Animal(name) {}
// Animal 没有默认构造函数，所以这里必须显式调用 Animal(name)
};
这个“显式调用基类构造函数”的步骤很容易被忽略。我见过不少刚接触C++的同事，在基类写了带参数的构造函数后，忘了给派生类加初始化列表，编译直接报错“no matching function for call to 'Animal::Animal()'”。好消息是编译器会拦着你，不会让你带着错误静默运行。
而Python就比较灵活，甚至有点“过于自由”。__init__ 不会自动调用父类的 __init__，你如果不主动写 super().__init__(name)，父类的初始化逻辑就完全不会执行。这不是报错，而是静默地不执行。结果就是父类定义的属性可能压根不存在：
python复制class Animal:
def __init__(self, name: str):
self.name = name
class Dog(Animal):
def __init__(self, name: str, breed: str):
self.breed = breed
# 没有调用 super().__init__(name)！
dog = Dog("旺财", "法斗")
print(dog.breed) # 正常输出
print(dog.name) # AttributeError: 'Dog' object has no attribute 'name'
析构的差异更大。C++支持RAII（资源获取即初始化），对象的析构函数在离开作用域时会被自动调用，你可以把释放文件句柄、归还锁、释放堆内存这些操作全部放在析构函数里。这保证了一个对象无论通过哪种路径离开作用域，资源都会被正确释放。
cpp复制class FileGuard {
public:
FileGuard(const std::string& path) { file_ = fopen(path.c_str(), "r"); }
~FileGuard() { if (file_) fclose(file_); }
private:
FILE* file_;
};
当 FileGuard 对象离开作用域时，析构函数被调用，文件句柄被自动关闭。这就是C++资源管理的基础。
而Python没有真正意义上的“自动析构保证”。Python的 __del__ 方法虽然看起来像析构函数，但调用时机完全由垃圾回收器决定，而且不保证程序退出时一定被调用。我之前维护过一段网络通信代码，有人试图在 __del__ 里关闭连接，结果程序退出时连接并没有被及时关闭，导致了资源泄漏。后来我把资源释放逻辑改成了 with 语句或显式调用的 close() 方法，才彻底解决。
所以你看，C++的继承链上有严格的构造和析构顺序，父类的构造先于子类，析构则相反。Python的继承链上没有这种强制性，构造者是你自己，弄不好就是一个半初始化对象。这是两者在使用习惯上需要刻意转换的地方。
3. 多继承与菱形继承：两种解法，两种痛
3.1 C++ 虚继承：解决菱形，同时带来构造顺序的坑
C++支持多继承，但不建议随便用，因为一旦出现菱形继承（两个基类继承同一个祖先，派生类同时继承这两个基类），就会导致祖先的副本出现两份。经典问题就是“钻石继承”。
cpp复制class Base {
public:
Base() { std::cout << "Base constructed" << std::endl; }
int value_;
};
class A : public Base {};
class B : public Base {};
class Derived : public A, public B {};
这种情况下，Derived 对象里包含两份 Base 子对象，value_ 也有两份，你访问 derived.value_ 时编译器直接报歧义错误。解决办法是通过虚继承：
cpp复制class A : virtual public Base {};
class B : virtual public Base {};
class Derived : public A, public B {};
这样一来，Derived 对象中只有一份共享的 Base 子对象。但这带来一个非常容易踩坑的问题：虚基类的构造顺序和大家想的不一样。
C++标准规定，虚基类由最派生类的构造函数负责初始化，并且先于所有非虚基类。也就是说，Derived 的构造函数里需要先调用 Base()，即使你没有显式写：
cpp复制class Derived : public A, public B {
public:
Derived() : Base(), A(), B() {
std::cout << "Derived constructed" << std::endl;
}
};
如果忘了写 Base()，编译器会去调用 Base 的默认构造函数。如果 Base 没有默认构造函数，编译直接报错。我实际项目中就遇到过一个：Base 构造函数需要传一个配置文件路径，结果在 Derived 里忘了初始化，编译器报错“no default constructor exists for class 'Base'”，当时查了半天才想起来虚基类初始化要在最派生类里做。
另外虚继承的析构顺序并不对称。构造顺序是虚基类最先，析构顺序是虚基类最后。这是为了确保最派生类的成员在使用虚基类成员时，虚基类仍然存在。这个规则平时不太容易注意到，但在内存池或者对象池释放顺序敏感的场合，会突然给你一个下马威。
3.2 Python 的 MRO：用 C3 算法保证顺序
Python同样支持多继承，但它的解决方法不是“让某个基类只保留一份副本”，而是通过一个精心计算的方法解析顺序（MRO）来确定每个名字应该去哪里找。Python 2.3 以后使用C3线性化算法，Python 3中所有类的MRO都是基于这个算法计算的。
python复制class Base:
def __init__(self):
print("Base init")
class A(Base):
def __init__(self):
super().__init__()
print("A init")
class B(Base):
def __init__(self):
super().__init__()
print("B init")
class Derived(A, B):
def __init__(self):
super().__init__()
print("Derived init")
当你实例化 Derived() 时，输出顺序是：
code复制Base init
B init
A init
Derived init
这个输出顺序可能出乎很多人的意料。直观想，Derived 继承自 A 和 B，那初始化的时候不该是 Base -> A -> B -> Derived 吗？为什么 B 先于 A？
因为 Derived 的MRO是 [Derived, A, B, Base, object]。super().__init__() 并不是简单地调用父类的 __init__，而是沿着MRO找下一个类的 __init__。所以在 A.__init__ 里调用 super().__init__()，去MRO里找 A 后面的类，也就是 B，于是先执行了 B.__init__。B.__init__ 里再调用 super().__init__()，才走到 Base。
理解这个机制以后，你再回头看这一段代码，就知道 super() 在Python多继承中的地位了。它不是一个简单的语法糖，而是协调整个MRO链的关键。如果一个中间类不好好调用 super().__init__()，整条链就断了，后面类的初始化逻辑全部不会执行。
3.3 一个菱形继承的完整对比
我再用一个更完整的例子把C++和Python的菱形继承放在一起看。
C++版本：
cpp复制#include <iostream>
class Base {
public:
Base() { std::cout << "Base" << std::endl; }
};
class A : virtual public Base {
public:
A() { std::cout << "A" << std::endl; }
};
class B : virtual public Base {
public:
B() { std::cout << "B" << std::endl; }
};
class Derived : public A, public B {
public:
Derived() { std::cout << "Derived" << std::endl; }
};
int main() {
Derived d;
return 0;
}
输出：
code复制Base
A
B
Derived
Python版本：
python复制class Base:
def __init__(self):
print("Base")
class A(Base):
def __init__(self):
super().__init__()
print("A")
class B(Base):
def __init__(self):
super().__init__()
print("B")
class Derived(A, B):
def __init__(self):
super().__init__()
print("Derived")
d = Derived()
输出：
code复制Base
B
A
Derived
注意差别：C++的构造顺序是 Base -> A -> B -> Derived，而Python的MRO走法让 B 跑到了 A 前面。原因就在于C++的虚继承构造顺序严格按照“虚基类最先、然后按继承声明顺序依次构造”，而Python的MRO则是一种线性化排序，它把 A 和 B 的相对顺序按照 Derived(A, B) 的声明来定，A 在MRO中更靠前，所以 A.__init__ 先执行，但在 A.__init__ 中调用 super() 又会跳到 B。
这两种输出顺序其实各有各的道理，但如果你不知道背后的机制，很容易被绕晕。我建议在实际项目里：C++的多继承尽量少用，虚继承能避开就避开；Python的多继承可以用，但每个参与多继承的类，都必须在 __init__ 里调用 super().__init__()，否则就破坏了协作链路。
4. 方法重写与多态：虚函数表 vs 鸭子类型
4.1 C++ 的 virtual、override 和 final 用起来要注意什么
C++的多态依赖虚函数和虚函数表。你给基类的函数加上 virtual，它就进入了虚函数表；派生类里同名同参的函数加上 override，编译器就会检查你写的签名是不是真的覆盖了基类虚函数。如果写法不匹配，override 关键字会直接报编译错误，这算是C++11以来最好用的检查机制之一。
cpp复制class Animal {
public:
virtual void speak() const { std::cout << "animal" << std::endl; }
virtual ~Animal() = default;
};
class Dog : public Animal {
public:
void speak() const override { std::cout << "dog" << std::endl; }
};
但有几个细节非常容易踩坑。
第一，析构函数必须是虚函数。这是C++继承里最重要的一条。如果你的基类指针指向派生类对象，delete 的时候如果析构不是虚函数，那么只会调用基类的析构函数，派生类里申请的内存或者持有的资源就泄漏了。
cpp复制Base* p = new Derived();
delete p; // 如果 ~Base() 不是 virtual，这里不会调用 ~Derived()
我刚工作那会儿就在一个插件系统里这么干过，结果是一堆通过派生类持有的数据库连接没有被关闭，测试环境跑几天数据库连接数就爆了。从那以后，只要是作为基类的类，析构函数永远加 virtual，这是铁律。
第二，非虚函数被重写时的“隐藏”行为。C++中如果基类有一个非虚成员函数 int f(int)，派生类定义了一个同名同参的 int f(int)，它不会进入虚函数表，派生类对象调用 f 时以派生类版本为准。当你用基类指针调用 basePtr->f(1) 时，调用的却是基类版本，这就造成了行为不一致。
更坑的是“隐藏”规则：只要派生类定义了一个同名的函数，不管参数列表是否一样，基类的所有同名重载都会被隐藏。比如基类有 void f(int) 和 void f(double)，派生类定义 void f(std::string)，那么 derived.f(1) 会编译失败，因为编译器找不到 f(int)，它只会看到被隐藏后的 f(std::string)。要解除隐藏，你必须在派生类里加一句 using Base::f;。
第三，final 关键字可以终止虚函数重写和类的继承。C++11 以后，一个类可以写成 class Dog final : public Animal，这个类就不能再被其他类继承了。一个虚函数可以写成 void speak() const override final，这样它的子类就不能再重写。这在框架设计时很有用，能直接把“这个类不允许再被继承”的语义声明清楚。
4.2 Python 的 super() 到底指向谁
Python的方法重写从语法层面看比C++简单得多，同名同参方法直接覆盖就行，不需要 virtual 也不需要用 override 声明。但这种“自由”在某些场景下会让人困惑，尤其是 super() 的指向问题。
Python的 super() 不是一个“父类对象”，而是一个帮助你在MRO上继续向后搜索的代理对象。普通场景下，super().method() 等价于沿着MRO找到下一个具有该方法的类。但在多继承中，super() 的调用顺序和我前面说的 super().__init__() 链是一模一样的逻辑。
我见过一个很典型的错误：两个独立的父类：
python复制class MixinA:
def hello(self):
print("Hello from A")
super().hello() # 问题：这里 super() 会调用 MRO 中的下一个类
class Base:
def hello(self):
print("Hello from Base")
如果你写 class Child(MixinA, Base): 并调用 Child().hello()，MRO是 [Child, MixinA, Base, object]，MixinA.hello 里的 super().hello() 会走到 Base.hello，输出两行。这是合理的。
但如果你写 class Child(Base, MixinA):，MRO是 [Child, Base, MixinA, object]，Child 没有重写 hello，所以直接调用 Base.hello，会输出 Hello from Base，并且后面的 MixinA.hello 不会执行，因为 Base.hello 里没有 super().hello()。这种情况下 MixinA 相当于被拉进了继承链里，但它的 hello 永远不被触发。
这个行为如果你没搞清楚，很容易写出“我以为 MRO 会这样，结果它那样”的代码。我后来总结的经验是：在Python多继承的协作链里，要么每个类的方法都调用 super().method()，形成一条完整的链；要么就别搞多继承，用组合。不要指望某个父类不调用 super() 时，多继承依然按照某种“直觉”运行。
Python的动态多态还有一个特点：它是不需要基类约束的鸭子类型。只要一个对象有 speak() 方法，你就能调用它，它不要求这个对象一定继承某个抽象基类。
python复制def make_speak(animal):
animal.speak() # 只要有 speak 方法就行
class Cat:
def speak(self):
print("meow")
这种写法在Python里非常常见，但如果你是从C++转过来的，可能会觉得“这也太野了”。C++里你要定义一个接口 ISpeakable，或者模板约束，才能做到类似的效果。Python里你只需要保证传入的对象有这个方法。所以写Python测试的时候，模拟对象（Mock）非常容易创建，不需要继承任何东西，这也是动态类型带来的灵活红利。
5. 访问控制与抽象接口设计：C++ 这么严，Python 这么松
5.1 C++ 的 public/protected/private 和友元机制
C++的访问控制是从语法层面强制的。类成员可以声明为 public（任何地方可访问）、protected（只有在类内部和派生类中可以访问）、private（只有类内部可以访问）。这种控制是编译期检查，你写了非法访问，编译器直接报错。
继承方式也有对应的访问控制修饰符：public 继承（保序基类的访问级别）、protected 继承（基类的 public/protected 都变成 protected）、private 继承（基类所有成员都变成 private）。实际工程中，绝大多数情况只用到 public 继承。private 继承偶尔用于“实现继承接口但不想公开父子关系”的场景，但可读性差，除非有充分理由，不建议使用。
cpp复制class Account {
public:
Account() : balance_(0.0) {}
void deposit(double amount) { balance_ += amount; }
double get_balance() const { return balance_; }
protected:
void set_balance(double b) { balance_ = b; }
private:
double balance_;
};
class SavingsAccount : public Account {
public:
void add_interest(double rate) {
double b = get_balance(); // 可以，public 方法
set_balance(b * (1 + rate)); // 可以，protected 方法
// balance_ += rate; // 不行！balance_ 是 private
}
};
C++还有个独特的友元机制：一个类可以声明 friend class Foo 或 friend void bar()，让指定的类或函数访问自己的 private 成员。这在实现某些内部工具、测试辅助类时很实用，但也会破坏封装边界，需要用得克制。
我在设计底层通信库的时候，就常用 friend class ConnectionFactory 的方式，让工厂类可以访问连接类的私有构造器，从而保证连接对象只能通过工厂创建，不允许外部直接 new。这个需求在Python里反而没法通过语法做到，只能靠约定和一个“私有”构造提示。
5.2 Python 的私有约定、property 和 ABC
Python没有真正的 private 关键字。类成员默认全部是公开的，不管是方法还是属性。开发者通常用以下约定来表达“别动它”：
_single_underscore：约定内部使用，外界不应直接访问。__double_underscore：触发名称改写（name mangling），实际存储名变为_ClassName__attribute，从而避免子类意外覆盖。
python复制class Account:
def __init__(self):
self.__balance = 0.0
def deposit(self, amount):
self.__balance += amount
def get_balance(self):
return self.__balance
class SavingsAccount(Account):
pass
注意，名称改写不是强制私有。你依然可以通过 account._Account__balance 访问这个“私有”属性。它只是防止你在继承体系中误用名字，并不是安全机制。真正的封装通常依赖 property 来实现对属性访问的控制：
python复制class Account:
def __init__(self):
self._balance = 0.0
@property
def balance(self):
return self._balance
@balance.setter
def balance(self, value):
if value < 0:
raise ValueError("balance cannot be negative")
self._balance = value
这样外部代码像访问普通属性一样 account.balance 去读取，但赋值时会经过校验逻辑。这是Python里非常推荐的做法，可以让你在不需要改变调用方代码的情况下，为属性增加限制或副作用。
接口设计方面，C++通过纯虚函数来定义抽象接口，类只要有一个纯虚函数就无法被实例化：
cpp复制class IShape {
public:
virtual double area() const = 0;
virtual ~IShape() = default;
};
Python则使用标准库的 ABC 模块：
python复制from abc import ABC, abstractmethod
class Shape(ABC):
@abstractmethod
def area(self) -> float:
pass
用 abc.ABC 作为基类或使用 metaclass=ABCMeta，加上 @abstractmethod 装饰器，同样能达到“不能直接实例化”的效果。而且Python还支持注册虚拟子类：
python复制class Shape(ABC):
@abstractmethod
def area(self) -> float:
pass
class Circle: # 没有继承 Shape
def area(self) -> float:
return 3.14 * self.radius ** 2
Shape.register(Circle) # 手动把 Circle 注册为 Shape 的虚拟子类
这样一来，isinstance(circle, Shape) 返回 True，但 Circle 并没有真正继承 Shape。这种灵活性是C++没有的。C++想要类似的效果，只能通过模板或外部注册表实现，比较绕。
6. 继承高频翻车现场与排查思路
6.1 C++ 基类析构函数没写 virtual，内存泄漏了
这个问题我在前面已经提到过，但值得单独放在翻车现场里再说一次。C++继承中如果基类析构函数不是虚函数，通过基类指针 delete 派生类对象，行为是未定义的。实际表现通常是派生类的析构函数没有被调用，如果派生类持有堆内存、锁、文件句柄等资源，全部泄漏。
cpp复制class Base {
public:
~Base() {} // 不写 virtual，问题就在这里
};
class Derived : public Base {
public:
Derived() { data_ = new int[100]; }
~Derived() { delete[] data_; }
private:
int* data_;
};
Base* p = new Derived();
delete p; // ~Derived() 不会被调用，data_ 泄漏
排查这类问题时，通常会用内存检测工具比如 Valgrind，看到“definitely lost”的堆内存分配记录，定位到 Derived 构造函数里的 new，但不知道泄漏的根源在析构函数没加 virtual。我自己的排查习惯是：如果看到类层级中出现基类指针删除派生类对象，优先检查基类析构是否 virtual，这能避免80%的资源泄漏问题。
6.2 Python 子类没调 super().init，对象初始化不完整
Python继承中，子类忘记调用 super().__init__() 是最常见的问题之一。前面已经给过例子。这个问题一般不报错，只是属性缺失，或行为不符合预期。有时候属性恰好存在于父类其他方法里，对象看起来能用，但关键状态没准备好，导致后续一系列诡异错误。
我在实际项目里维护过一个数据解析服务，多个解析器继承一个 BaseParser。后来有人新增了一个 JsonParser，重写了 __init__，但没有调用 super().__init__()。结果 BaseParser 里设置的一些元数据标志位（比如 self.initialized = True）没有被设置，服务启动时报“ConnectionRefusedError”，查了很久才发现是初始化链断了。
排查这种问题，一个很实用的技巧是在基类的 __init__ 末尾加一行 print(f"{self.__class__.__name__} initialized")，或者干脆在初始化完成时设置一个 self._init_complete = True 标志。子类如果忘记调用 super().__init__()，调试时看日志就能发现输出缺失。
对于多继承场景，建议统一采用“每个类的 __init__ 都调用 super().__init__()”的写法，这样整条MRO链是完整的，谁漏了调用都能在追溯时发现断点。这也是Python社区比较推荐的做法。
6.3 对象切片、类型转换、isinstance 那些容易被忽视的细节
C++中如果把派生类对象按值赋给基类变量，会发生对象切片（slicing）：派生类的部分数据被切掉，只剩下基类子对象。
cpp复制Derived d;
Base b = d; // 切片，派生类部分被切除
Base& ref = d; // 引用，不会切片
Base* ptr = &d; // 指针，不会切片
对象切片经常导致意想不到的错误。我有一次在一个函数里按值传递基类参数，结果传入派生类对象时，虚函数调用表现正常，但派生类的成员变量全部丢失，数据全变成了默认值。后来改成传引用，问题消失。在C++里，面向对象编程的接口参数尽量用引用或指针，不要按值传多态对象。
Python没有切片问题，因为Python的“变量”都是对象引用，永远不存在“把对象复制成基类类型”的操作。不管你怎么赋，dog 永远是 Dog 实例，类型不会变化。
类型判断方面，C++的 dynamic_cast 可以在运行时把一个基类指针转回派生类指针，判断转换是否成功来体现实例的真实类型：
cpp复制Base* p = dynamic_cast<Base*>(&derived);
Dog* dog = dynamic_cast<Dog*>(p);
if (dog) {
// p 确实指向了一个 Dog 对象
}
Python的 isinstance 和 issubclass 则直接支持继承体系的判断，同时还能处理虚拟子类注册的情况：
python复制print(isinstance(dog, Dog)) # True
print(isinstance(dog, Animal)) # True，因为 Dog 继承自 Animal
print(issubclass(Circle, Shape)) # True，因为我们注册过虚拟子类
另外一个容易忽略的小细节是Python中的“类变量 vs 实例变量”。继承中，子类访问的类属性如果是在基类定义的，实际查找时会沿着MRO找到基类上的那个类属性，但如果在子类上赋值，会创建子类自己的类属性，不会影响基类。C++里则没有这种问题，因为成员变量属于各对象的实例数据，不会出现“共享类变量”这种语义。
python复制class A:
items = []
class B(A):
pass
b1 = B()
b2 = B()
b1.items.append(1)
print(b2.items) # [1]，因为 items 是 A 类的类属性，所有实例共享
如果你没有意识到 items 是类属性，永远都不会想到 b1 往列表里加的元素会影响 b2。这种问题在并发场景下特别要命。我自己就在一个多线程任务分发器里遇到过：每个继承自基类的子类对象共享了同一个任务列表，导致任务被多个线程重复处理。解决方法是把可变对象放到 __init__ 里作为实例属性，而不是在类体中定义。
到这里，Python和C++在类继承方面的差异也就讲得七七八八了。我个人在实际项目里的体会是：这两种语言的继承机制虽然功能相似，但底层哲学完全不同。C++把继承当成内存布局的复用和编译期的契约，你需要在写代码时对对象的生命周期、虚函数表、构造析构顺序有清晰的把握；Python把继承当成一个运行时查找名字的顺序链，你需要在调用链的协作上保持克制，尤其是多继承里 super() 的用法。两者没有优劣之分，只是适用场景不同。如果你的项目追求极致的性能和资源可控性，C++的继承模型会让你更有掌控力；如果你的项目更看重迭代速度和灵活性，Python的继承方式会让你开发效率更高。
最后再分享一个小技巧：当你需要在这两种语言之间切换时，别急着用自己熟悉的一方的思维去套另一方的写法。先花点时间去理解“这个语言里继承真正做了什么”，很多冲突和误解其实都是思维模型没切换过来导致的。