技术博客
std::assume_aligned 不是让编译器“对齐内存”，而是告诉它“这块指针指向的内存，**已知**按指定字节数对齐”。它本身不分配、不移动、不校验——只是个提示。编译器信了，才可能生成 movaps、vaddps 这类要求 16/32/64 字节对齐的 SIMD 指令；不信或没用对，就退回 movups 等非对齐版本，性能掉一截。
不加 virtual，哪怕子类写了同名函数，调用时也完全不会走多态——编译器直接按指针/引用的静态类型决定调用哪个函数。这是最常踩的坑：以为“名字一样+继承了”就自动多态，结果 Base* p = new Derived(); p->func(); 调的还是 Base::func()。
很多人写 sort(v.begin(), v.end(), cmp) 时，cmp 是个普通函数，却在类内定义成 bool cmp(…) —— 这会编译失败，因为非静态成员函数有隐式 this 指针，类型不匹配。C++ 要求比较器能被直接调用，且签名形如 bool( const T&, const T& )。
Go 语言没有传统意义上的类（class），但通过结构体（struct）和方法（method）可以自然地实现面向对象编程的核心思想：封装、组合与行为绑定。关键在于理解 方法是绑定到特定类型的函数，而结构体就是最常用、最直观的自定义类型载体。
unsafe 包本身不提供“安全”的指针转换——它绕过 Go 类型系统，所谓“安全”只取决于你是否严格遵守内存布局、生命周期和对齐约束。
Go 的单例靠包级变量 + 私有构造函数“约定俗成”，但 reflect 能绕过导出性检查，直接调用未导出的构造函数或复制结构体字段。一旦有人用 reflect.New() + reflect.Value.Elem().Set() 或 reflect.ValueOf(&instance).Elem().Interface() 二次实例化，单例就失效了。
Go 语言里对 nil 指针取值（比如 *p）或调用方法，会立即触发运行时 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是编译错误，而是在运行时崩溃——所以空指针检查不是“可选优化”，而是必须的防御动作。
直接写 using 比 typedef 更直观，尤其面对模板时不会绕晕。比如想给 std::vector<int></int> 起个短名叫 IntVec，就这么写：
placement new 不是“另一种 new”，而是 operator new 的重载形式，它不分配内存，只在已有的内存地址上构造对象。你不能用它替代 new 去申请堆内存——它根本不会调用 ::operator new(size_t)，也不会管理内存生命周期。
Go 的 reflect.New 只接受 reflect.Type，且该类型必须是可寻址的——也就是不能直接传 struct 类型字面量，得传它的指针类型。常见错误是写 reflect.New(reflect.TypeOf(MyStruct{}))，这会 panic：「panic: reflect: New(nil)」，因为 reflect.TypeOf(MyStruct{}) 返回的是值类型，而 reflect.New 要求的是类型本身（非接口、非 nil）。