diff --git a/README.md b/README.md
index dd8a5b12d..aaafc06e4 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@
 ---
 
 <!-- COVERAGE_START -->
-![English Coverage](https://img.shields.io/badge/en_coverage-100%25-green.svg) 592/594 docs translated
+![English Coverage](https://img.shields.io/badge/en_coverage-100%25-green.svg) 602/604 docs translated
 <!-- COVERAGE_END -->
 
 ## 这是什么项目
diff --git a/code/examples/vol4/vol1-basics-cpp11-14/comparable_mixin.cpp b/code/examples/vol4/vol1-basics-cpp11-14/comparable_mixin.cpp
new file mode 100644
index 000000000..7237d05b0
--- /dev/null
+++ b/code/examples/vol4/vol1-basics-cpp11-14/comparable_mixin.cpp
@@ -0,0 +1,30 @@
+// Comparable<Derived>:CRTP mixin,只实现 < 和 ==,自动补齐 > <= >= !=
+// 对应文章:documents/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
+// 编译:g++ -Wall -Wextra -std=c++20 comparable_mixin.cpp -o comparable && ./comparable
+#include <iostream>
+
+template <typename Derived> struct Comparable {
+    friend bool operator>(const Derived& a, const Derived& b) { return b < a; }
+    friend bool operator<=(const Derived& a, const Derived& b) { return !(b < a); }
+    friend bool operator>=(const Derived& a, const Derived& b) { return !(a < b); }
+    friend bool operator!=(const Derived& a, const Derived& b) { return !(a == b); }
+};
+
+struct Point : Comparable<Point> {
+    int x, y;
+    Point(int x_, int y_) : x(x_), y(y_) {}
+    // 只实现 < 和 ==,其余四个由 Comparable<Point> 自动补齐
+    friend bool operator<(const Point& a, const Point& b) { return a.x < b.x; }
+    friend bool operator==(const Point& a, const Point& b) { return a.x == b.x; }
+};
+
+int main() {
+    Point p1{1, 2}, p2{3, 4};
+    std::cout << std::boolalpha;
+    std::cout << "p1 < p2:  " << (p1 < p2) << "\n";
+    std::cout << "p1 > p2:  " << (p1 > p2) << "\n";
+    std::cout << "p1 <= p2: " << (p1 <= p2) << "\n";
+    std::cout << "p1 >= p2: " << (p1 >= p2) << "\n";
+    std::cout << "p1 != p2: " << (p1 != p2) << "\n";
+    return 0;
+}
diff --git a/code/examples/vol4/vol1-basics-cpp11-14/crtp_static_polymorphism.cpp b/code/examples/vol4/vol1-basics-cpp11-14/crtp_static_polymorphism.cpp
new file mode 100644
index 000000000..c879237c9
--- /dev/null
+++ b/code/examples/vol4/vol1-basics-cpp11-14/crtp_static_polymorphism.cpp
@@ -0,0 +1,47 @@
+// CRTP 静态多态:派生类把自己传给基类,编译期绑定,无 vtable 无运行时分派
+// 对应文章:documents/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
+// 编译运行:g++ -Wall -Wextra -std=c++20 crtp_static_polymorphism.cpp -o crtp && ./crtp
+// 看零开销汇编:g++ -O2 -std=c++20 -DCRTP_BENCH -S crtp_static_polymorphism.cpp -o crtp.s
+//   use_crtp() 会被完全内联成 mov $0x2a,%eax; ret(对比虚函数版的 vtable 解引用)
+#include <iostream>
+
+template <typename Derived> struct Shape {
+    const char* name() { return static_cast<Derived*>(this)->name_impl(); }
+    double area() { return static_cast<Derived*>(this)->area_impl(); }
+};
+
+struct Circle : Shape<Circle> {
+    double r;
+    explicit Circle(double r_) : r(r_) {}
+    const char* name_impl() { return "Circle"; }
+    double area_impl() { return 3.14159 * r * r; }
+};
+
+struct Square : Shape<Square> {
+    double side;
+    explicit Square(double s) : side(s) {}
+    const char* name_impl() { return "Square"; }
+    double area_impl() { return side * side; }
+};
+
+#ifdef CRTP_BENCH
+// 汇编基准:use_crtp 在 -O2 下被完全内联,直接返回常量 42,零函数调用
+template <typename D> struct BenchBase {
+    int compute() { return static_cast<D*>(this)->compute_impl(); }
+};
+struct BenchConcrete : BenchBase<BenchConcrete> {
+    int compute_impl() { return 42; }
+};
+int use_crtp() {
+    BenchConcrete c;
+    return c.compute();
+}
+#endif
+
+int main() {
+    Circle c{2.0};
+    Square s{3.0};
+    std::cout << c.name() << " area = " << c.area() << "\n"; // Circle 走 Circle::area_impl
+    std::cout << s.name() << " area = " << s.area() << "\n"; // Square 走 Square::area_impl
+    return 0;
+}
diff --git a/code/examples/vol4/vol1-basics-cpp11-14/fixed_vector.cpp b/code/examples/vol4/vol1-basics-cpp11-14/fixed_vector.cpp
new file mode 100644
index 000000000..02e166358
--- /dev/null
+++ b/code/examples/vol4/vol1-basics-cpp11-14/fixed_vector.cpp
@@ -0,0 +1,46 @@
+// fixed_vector<T, N>:编译期定长、连续存储、零动态分配的 vector
+// 对应文章:documents/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md
+// 编译:g++ -Wall -Wextra -std=c++20 fixed_vector.cpp -o fixed_vector && ./fixed_vector
+#include <array>
+#include <cstddef>
+#include <iostream>
+#include <stdexcept>
+
+template <typename T, std::size_t N> class FixedVector {
+    std::array<T, N> data_{};
+    std::size_t size_ = 0;
+
+  public:
+    static constexpr std::size_t capacity_v = N;
+
+    constexpr void push_back(const T& value) {
+        if (size_ >= N)
+            throw std::out_of_range("FixedVector full");
+        data_[size_++] = value;
+    }
+    constexpr T& operator[](std::size_t i) { return data_[i]; }
+    constexpr const T& operator[](std::size_t i) const { return data_[i]; }
+    constexpr std::size_t size() const { return size_; }
+
+    // 裸指针当迭代器:元素连续存储,T* 天生满足随机访问迭代器要求
+    constexpr T* begin() { return data_.data(); }
+    constexpr T* end() { return data_.data() + size_; }
+    constexpr const T* begin() const { return data_.data(); }
+    constexpr const T* end() const { return data_.data() + size_; }
+};
+
+int main() {
+    FixedVector<int, 8> v;
+    for (int i = 1; i <= 5; ++i)
+        v.push_back(i * 10);
+
+    std::cout << "size = " << v.size() << " capacity = " << decltype(v)::capacity_v << "\n";
+    std::cout << "elements: ";
+    for (auto x : v)
+        std::cout << x << " ";
+    std::cout << "\n";
+    std::cout << "v[2] = " << v[2] << "\n";
+    std::cout << "sizeof(FixedVector<int,8>) = " << sizeof(FixedVector<int, 8>) << "\n";
+    std::cout << "sizeof(int*) = " << sizeof(int*) << " (动态 vector 至少含 3 个指针 + 堆分配)\n";
+    return 0;
+}
diff --git a/code/examples/vol4/vol1-basics-cpp11-14/type_traits_from_scratch.cpp b/code/examples/vol4/vol1-basics-cpp11-14/type_traits_from_scratch.cpp
new file mode 100644
index 000000000..a126c5c96
--- /dev/null
+++ b/code/examples/vol4/vol1-basics-cpp11-14/type_traits_from_scratch.cpp
@@ -0,0 +1,50 @@
+// 手写 type traits:主模板 + 偏特化,看穿 <type_traits> 的实现原理
+// 对应文章:documents/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md
+// 编译:g++ -Wall -Wextra -std=c++20 type_traits_from_scratch.cpp -o type_traits && ./type_traits
+#include <iostream>
+
+// is_pointer:主模板 false,指针偏特化 true
+template <typename T> struct is_pointer {
+    static constexpr bool value = false;
+};
+template <typename T> struct is_pointer<T*> {
+    static constexpr bool value = true;
+};
+
+// is_const:主模板 false,const T 偏特化 true(注意 const T* 不算,得 T 本身是 const)
+template <typename T> struct is_const {
+    static constexpr bool value = false;
+};
+template <typename T> struct is_const<const T> {
+    static constexpr bool value = true;
+};
+
+// is_reference:主模板 false,T& / T&& 偏特化 true
+template <typename T> struct is_reference {
+    static constexpr bool value = false;
+};
+template <typename T> struct is_reference<T&> {
+    static constexpr bool value = true;
+};
+template <typename T> struct is_reference<T&&> {
+    static constexpr bool value = true;
+};
+
+// C++14 变量模板简写(和标准库 _v 后缀同一思路)
+template <typename T> constexpr bool is_pointer_v = is_pointer<T>::value;
+
+int main() {
+    std::cout << std::boolalpha;
+    std::cout << "is_pointer<int>      = " << is_pointer<int>::value << "\n";
+    std::cout << "is_pointer<int*>     = " << is_pointer<int*>::value << "\n";
+    std::cout << "is_pointer<int**>    = " << is_pointer<int**>::value << "\n";
+    std::cout << "is_const<const int>  = " << is_const<const int>::value << "\n";
+    std::cout << "is_const<int>        = " << is_const<int>::value << "\n";
+    std::cout << "is_const<const int*> = " << is_const<const int*>::value
+              << " (指针自身非 const,指向 const)\n";
+    std::cout << "is_const<int* const> = " << is_const<int* const>::value << " (指针自身 const)\n";
+    std::cout << "is_reference<int&>   = " << is_reference<int&>::value << "\n";
+    std::cout << "is_reference<int&&>  = " << is_reference<int&&>::value << "\n";
+    std::cout << "is_pointer_v<double> = " << is_pointer_v<double> << " (_v 简写)\n";
+    return 0;
+}
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md
new file mode 100644
index 000000000..a49dc1420
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md
@@ -0,0 +1,212 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 'Strip templates back to what they really are: a code recipe with placeholders.
+  How they differ from macros and virtual dispatch, and the four kinds of template
+  entities in C++ (functions, classes, variables, aliases).'
+difficulty: intermediate
+order: 1
+platform: host
+prerequisites:
+- Volume 1 · Function Templates
+reading_time_minutes: 11
+related:
+- 'Function Templates, In Depth: Compilation Model and extern template'
+- 'Class Templates: Members, Dependent Names, Lazy Instantiation'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Templates, From Scratch: A Code Recipe with Placeholders'
+---
+# Templates, From Scratch: A Code Recipe with Placeholders
+
+We already wrote function templates back in Volume 1. We know that `template <typename T> T max_value(T a, T b)` lets the compiler stamp out a version for `int`, for `double`, for `std::string`. This volume stops at "how to use them" and asks different questions. What is a template, really? How does it pull off "write once, fit any type"? And what does that mechanism cost? Get the under-the-hood details straight, and reading the STL source, reading template-heavy industrial code like Chromium, or writing a library of your own stops feeling intimidating.
+
+## What a Template Actually Is: A Code Recipe with Placeholders
+
+I like to think of a template as a **code recipe**. The template itself is not code; it is a description of how the code should be written. `T` is a placeholder in the recipe. It says "leave this blank for now, fill it in when the recipe is actually used."
+
+```cpp
+template <typename T>
+T max_value(T a, T b) {
+    return (a > b) ? a : b;
+}
+```
+
+These lines produce no machine code on their own. The compiler just records the recipe. What actually produces machine code is **instantiation**. When we write `max_value(3, 5)`, the compiler sees that `3` and `5` are both `int`, copies the recipe with `T` replaced by `int`, and gets a real `int max_value(int, int)` function. That copy is what gets compiled.
+
+```cpp
+int x = max_value(3, 5);        // T=int, compiler stamps out an int version
+double y = max_value(1.0, 2.0); // T=double, stamps out a double version
+```
+
+These two calls produce two completely independent functions, each compiled separately. The effect is the same as if you had written two overloads by hand.
+
+Here is a counterintuitive point worth pausing on. Many people assume a template picks a version at runtime based on type. It does not. It generates a separate version at compile time for every type you use. So a template call has **no runtime overhead**: you are calling an ordinary function, with no vtable dispatch. The cost comes later, and we will get to it.
+
+::: warning A placeholder is not a macro substitution
+Some people read templates as "a fancier macro substitution," and that is half right. A macro (`#define`) is pure text replacement at the preprocessing stage. It ignores types, ignores scope, and trips you up the moment you stop paying attention. Template substitution happens during compilation. The compiler knows `T` is a type, and it runs type checking, overload resolution, and name lookup on it. When we get to two-phase lookup later, you will see that this mechanism is far more precise than a macro. Treating templates as "a macro with type checking" is fine as a first impression, but do not stop there.
+:::
+
+## Why Not a Macro, and Why Not a Virtual Function
+
+"Same logic, different types" is a need C++ answers in several ways. Let us line up the three most often compared.
+
+Macros. `#define max(a, b) ((a) > (b) ? (a) : (b))` works, but it is pure text replacement at preprocessing. Arguments get evaluated twice, types are ignored, there is no scope, and the debugger never sees it. Back in Volume 1 we mentioned the `max` macro from `<windows.h>` on Windows, the one that sends your blood pressure through the roof. Anything a macro can do, a template does better.
+
+Virtual dispatch. Write `max` as a virtual function, and the right implementation is picked at runtime based on the actual type of the object. This forces every participating type into one inheritance hierarchy, and every call goes through a vtable lookup, which costs runtime. Worse, builtin types like `int` and `double` cannot enter your hierarchy at all.
+
+Templates. The compiler generates a separate copy for every type used, and the call goes to an ordinary, inlineable function. No inheritance hierarchy required. Builtin types and user-defined types are treated the same. No runtime dispatch.
+
+None of these replaces the others. Virtual dispatch fits "one interface, implementation decided at runtime" cases like plugin systems or GUI event dispatch. Templates fit "one piece of logic, type known at compile time" cases like containers and algorithms. As for macros, mostly avoid them when you can.
+
+## C++ Has Four Kinds of Template Entities
+
+A lot of people think templates come in two flavors, function templates and class templates. The C++ standard actually defines four kinds of entities a template can produce. cppreference puts it plainly: a template is a C++ entity that defines a family of entities.
+
+A function template defines a family of functions; `std::max` and `std::sort` are examples. A class template defines a family of classes; `std::vector` and `std::map` are examples. Both have been around since C++98, and these are the two you know best. There are two newer ones. A variable template (since C++14) defines a family of variables or static members. An alias template (since C++11) defines a family of type aliases.
+
+Variable templates answer a plain need: attach a constant to "each type." Before C++14, people simulated this with a static member of a class template.
+
+```cpp
+// The old way, before C++14: simulate "a parameterized constant" with a class template static member
+template <typename T>
+struct pi_trait {
+    static constexpr T value = T(3.1415926535897932385L);
+};
+double r = pi_trait<double>::value * 2.0;
+```
+
+C++14 gave us variable templates, and you can write it as a single parameterized variable, much cleaner.
+
+```cpp
+template <typename T>
+constexpr T pi = T(3.1415926535897932385L);  // variable template
+
+double r = pi<double> * 2.0;  // reads like an ordinary constant, just with a <T>
+```
+
+Part of the reason `std::numeric_limits<T>::max()` is a function rather than a variable is that variable templates did not exist when it was born. `std::tuple_size` and `std::extent` later grew matching `_v` variable-template versions (things like `std::extent_v<T>`, introduced in C++17), precisely so you could stop writing `::value`. The feature-test macro on cppreference is `__cpp_variable_templates = 201304L`, tied to C++14.
+
+Alias templates answer the need to give a family of types a short name.
+
+```cpp
+// Before alias templates, naming vector<T> meant borrowing a nested using inside a class template
+template <typename T>
+struct vec_alias { using type = std::vector<T>; };
+typename vec_alias<int>::type v;  // typename, then ::type, noisy
+
+// C++11 alias template, one line
+template <typename T>
+using vec = std::vector<T>;
+vec<int> v;  // clean
+```
+
+This volume has a whole piece on alias templates later. For now, just hold this impression: **in C++, it is not only functions and classes that can be parameterized**.
+
+## Three Kinds of Template Parameters
+
+The "placeholder" in a template comes in three forms.
+
+A type parameter, written `typename T` or `class T`, stands in for a type. This is the most common. A non-type parameter, written like `template <int N>`, stands in for a compile-time **value**: an integer, a pointer, a reference, and since C++20 a floating-point value or a class type that meets certain conditions. A template template parameter stands in for a template itself.
+
+```cpp
+template <typename T, std::size_t N>   // T is a type parameter, N is a non-type parameter
+struct array {
+    T data[N];
+};
+
+template <template <typename> class Container>  // Container is a template template parameter
+struct wrapper {
+    Container<int> c;
+};
+```
+
+`std::array<T, N>` is the classic pairing of the first two: `T` is the element type, `N` is the size, and `N` must be known at compile time. Template template parameters are rare in day-to-day code, but they show up when you write higher-order generic libraries (say, a policy that swaps out the underlying container). All three get their own treatment later in this volume, and the non-type parameter piece spends time on how much C++20 loosened the rules.
+
+## Templates Are Compile-Time Turing Complete
+
+This deserves a section of its own, because it determines how far templates can go. **The C++ template mechanism is Turing complete.** Given the patience, you can do arbitrary computation at compile time with templates: branching, looping (faked with recursion), any logic, all finished before the program runs. What you get at runtime is a precomputed result.
+
+A minimal example, computing factorials at compile time.
+
+```cpp
+template <unsigned N>
+struct Factorial {
+    static constexpr unsigned value = N * Factorial<N - 1>::value;
+};
+
+template <>
+struct Factorial<0> {              // recursion base: 0! = 1
+    static constexpr unsigned value = 1;
+};
+
+template <unsigned N>
+constexpr unsigned factorial_v = Factorial<N>::value;  // C++14 variable template, convenient
+```
+
+Run it, and all the multiplication happened at compile time.
+
+```bash
+$ g++ -std=c++14 factorial.cpp -o factorial && ./factorial
+5! = 120
+10! = 3628800
+```
+
+```cpp
+static_assert(Factorial<5>::value == 120, "");      // checked at compile time
+static_assert(factorial_v<10> == 3628800, "");
+```
+
+`Factorial<5>::value` is already `120` before the program starts. This is the root of template metaprogramming (TMP): push computation into compile time. It powers impressive things, expression templates, compile-time strings, `constexpr` parsing all build on it, at the cost of slow builds, unreadable errors, and code that is hard to follow. Part three of this volume (C++20/23 metaprogramming) is about how C++ uses `concepts`, `consteval`, and `if constexpr` to drag TMP out of "dark arts" and into "code a person can write." For this piece, remember one thing: **a template does not only generate code, it can compute at compile time**.
+
+## The Cost: Instantiation, Code Bloat, Header-Only
+
+Templates are not free. There are three costs.
+
+The first is **lazy instantiation**. Only the member functions of a class template that are actually used get instantiated. Writing `std::vector<Heavy>` does not instantiate every member function of `vector`, only the ones you call. This is why the STL dares to pack so much into one template. You do not pay for what you do not use.
+
+```cpp
+template <typename T>
+struct Demo {
+    void used_function() { T t{}; /* ... */ }
+    void unused_function() {
+        // Even if this body refers to a member that does not exist on T,
+        // it will not error. This function is never called, so it is never instantiated.
+    }
+};
+
+int main() {
+    Demo<int> d;
+    d.used_function();   // only this one gets instantiated
+    // unused_function() is never called, so it is never instantiated,
+    // and the compiler never sees the nonsense inside it
+}
+```
+
+This cuts both ways. The upside is faster builds and smaller binaries. The downside is that some errors stay hidden until you actually use the thing.
+
+The second is **code bloat**. Every type you use gets its own copy. `max_value` used with `int`, `double`, and `std::string` is three functions. For a small function this is nothing. For large templates (say, the full specialization of some STL algorithm), it piles up and the binary grows noticeably. The function-template-in-depth piece in this volume covers `extern template`, the tool for keeping this bloat under control.
+
+The third is **header-only**. A template definition has to be visible at the point where it is instantiated, so almost every template library is a header-only library. boost is the canonical example. You cannot do what ordinary functions do, put the declaration in a header and the implementation in a `.cpp`. This is a direct cause of the old "C++ builds slowly" complaint: every translation unit re-parses the template definitions. C++20 modules exist to treat this disease, but that is a separate, large topic.
+
+## export template: An Abandoned Attempt
+
+On the subject of "the definition must be visible," the C++98 committee did offer a way out, called `export template`. The idea was beautiful: a template marked `export` could be instantiated by users who only saw the declaration, no need to include the definition, and you would get separate compilation for templates.
+
+Reality was unkind. Across the entire C++98 standard, only the Edison Design Group (EDG) front end and the Comeau compiler built on it ever implemented `export template`. GCC, Clang, and MSVC never did. The mechanism was enormously complex to implement, and the payoff was unclear. C++11 removed it from the standard entirely. cppreference marks it `(until C++11)`.
+
+The lesson here is that **separate compilation for templates is still an unsolved problem**. `extern template` cuts down redundant instantiation, but it does not truly separate declaration from definition. C++20 modules are a different, new answer, and their ecosystem is still being built. For now, template code still basically has to live in headers. That is the reality C++ programmers work in.
+
+## The Road This Volume Takes
+
+This piece stripped templates back to what they are: a code recipe with placeholders, stamped into real code at compile time, with no runtime overhead, paid for in code bloat and the need to live in headers. From here we move from "can use" to "can write libraries with." The next piece breaks open the compilation model of function templates, `extern template`, and the classic trap that function templates cannot be partially specialized. After that comes class templates, specialization and partial specialization, non-type parameters, two-phase name lookup, friend injection, and alias templates, closing with CRTP for static polymorphism and a `fixed_vector` project that strings everything together.
+
+Read this far, and you should feel grounded on "what a template is." The rest of the volume takes the "why" apart, piece by piece.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md
new file mode 100644
index 000000000..3294202fc
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md
@@ -0,0 +1,270 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 'Re-reading function templates from a library writer''s angle: why the
+  inclusion model forces templates into headers, how explicit instantiation and extern
+  template control code bloat, and the classic trap that function templates cannot
+  be partially specialized.'
+difficulty: intermediate
+order: 2
+platform: host
+prerequisites:
+- Volume 1 · Function Templates
+- 'Templates, From Scratch: A Code Recipe with Placeholders'
+reading_time_minutes: 11
+related:
+- 'Class Templates: Members, Dependent Names, Lazy Instantiation'
+- 'Template Specialization and Partial Specialization: The Art of Pattern Matching'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Function Templates, In Depth: Compilation Model and the No-Partial-Specialization
+  Trap'
+---
+# Function Templates, In Depth: Compilation Model and the No-Partial-Specialization Trap
+
+Volume 1 already covered function templates: the syntax, instantiation, deduction, specialization, and overloading. This piece shifts perspective to "I want to build a library with templates," where three things are unavoidable. Why the compilation model for templates differs from ordinary functions. How explicit instantiation and `extern template` help you control code bloat. And a trap that can leave you staring at the screen for half an hour: function templates cannot be partially specialized. Get these three straight, and reading the source of STL or template-heavy libraries like Eigen starts to make sense, why they organize the code the way they do.
+
+## The Inclusion Model: Why Templates Live in Headers
+
+First, recall how an ordinary function is split across files. The declaration goes in a header `add.h`, the implementation in `add.cpp`, and anyone else `#include "add.h"` to use it. The compiler only sees the declaration at the call site, and the linker later binds the call to the implementation in `add.cpp`. This is **separate compilation**, an old C/C++ tradition.
+
+Templates do not work that way. Templates use the **inclusion model**: the definition of a template must be fully visible at the point where it is instantiated. You cannot put a function template declaration in a header, the definition in a `.cpp`, and then use it from another translation unit (TU). Instantiation happens at compile time, and the compiler must substitute `T` with the concrete type and generate code on the spot at the call site. That generation needs the full template definition.
+
+```cpp
+// add.h -- only a declaration, will this work?
+template <typename T>
+T add(T a, T b);   // declaration only
+```
+
+```cpp
+// add.cpp -- the definition
+template <typename T>
+T add(T a, T b) { return a + b; }
+```
+
+```cpp
+// main.cpp
+#include "add.h"
+int main() {
+    return add(1, 2);   // link error! undefined reference to `add<int>(int, int)`
+}
+```
+
+This compiles, but the link fails. In `main.cpp` the compiler cannot see the definition of `add`, so it cannot instantiate `add<int>`, and what it leaves behind is an unresolved symbol reference. In `add.cpp`, because nobody "uses" `add`, the compiler never instantiates any version at all. The two sides never line up, and the linker reports undefined reference.
+
+The fix is plain: move the definition back into the header.
+
+```cpp
+// add.h -- definition lives in the header
+template <typename T>
+T add(T a, T b) { return a + b; }
+```
+
+This is why nearly every template library is a header-only library. boost is the canonical example. The cost was mentioned in the previous piece: every TU that `#include`s it re-parses the template definition, which is why large projects compile slowly.
+
+The C++98 committee did try to fix this with `export template`, attempting to give templates their own separate compilation. Only EDG ever implemented it, the major compilers all bailed, and C++11 removed `export` entirely. So today the inclusion model is the only realistic choice for templates. Explicit instantiation, covered next, is a way to "save a little" within the inclusion model. It is not real separate compilation.
+
+## Explicit Instantiation: Manually Placing Instantiation Points
+
+By default, templates use **implicit instantiation**: wherever you use `add<int>`, the compiler generates a copy of `add<int>` in that translation unit. Ten TUs all using `add<int>` means ten copies generated, with duplicates merged at link time. Merging is free; generating is not. Every TU has to do the substitution and compilation all over again, which is the root of the slowness.
+
+**Explicit instantiation** lets you manually say "generate the code for this version, here."
+
+An explicit instantiation definition starts with the `template` keyword, followed by a concrete signature with no `template<>`:
+
+```cpp
+template <typename T>
+T add(T a, T b) { return a + b; }
+
+// explicit instantiation definition: force the compiler to generate add<double> in this TU
+template double add<double>(double, double);
+```
+
+This line tells the compiler: whether or not this TU actually uses `add<double>`, generate it anyway. It compiles and runs fine.
+
+```bash
+$ g++ -std=c++17 explicit_inst.cpp -o explicit_inst && ./explicit_inst
+add(1.0, 2.0) = 3
+add(1, 2) = 3
+```
+
+Paired with it is the `extern template` declaration. It says "this version has already been instantiated in another TU, so do not generate it here, use the one from there."
+
+```cpp
+// In some .cpp: explicit instantiation definition, actually emits the code
+//   template int add<int>(int, int);
+
+// In other .cpp / .h: a declaration, generates nothing, links to the other one
+extern template int add<int>(int, int);
+```
+
+Let us run a two-TU example and see it link.
+
+```cpp
+// tu_a.cpp -- implicit instantiation of doubler<int> happens here (call_a uses it)
+template <typename T>
+T doubler(T x) { return x * 2; }
+int call_a() { return doubler(21); }
+```
+
+```cpp
+// tu_b.cpp -- declare that doubler<int> is instantiated elsewhere; do not generate here
+template <typename T>
+T doubler(T x) { return x * 2; }
+extern template int doubler<int>(int);
+int call_b() { return doubler(21); }
+```
+
+```cpp
+// main_ab.cpp
+#include <iostream>
+int call_a();
+int call_b();
+int main() {
+    std::cout << "call_a=" << call_a() << " call_b=" << call_b() << "\n";
+}
+```
+
+```bash
+$ g++ -std=c++17 tu_a.cpp tu_b.cpp main_ab.cpp -o main_ab && ./main_ab
+call_a=42 call_b=42
+```
+
+`tu_b` calls `doubler(21)` too, but because of the `extern template` declaration it does not emit `doubler<int>`. It waits for the linker to bind to the copy `tu_a` produced. The link succeeds and the result is correct.
+
+The real home for this mechanism is library authoring. The standard library uses this pattern heavily. High-frequency combinations like `std::basic_string<char>` and `std::vector<int>` are pre-instantiated inside libstdc++ source files, and the public headers declare `extern template` for user code. That way tens of thousands of user TUs no longer each reinstantiate the dozens of member functions of `std::string`. Both compile time and binary size drop noticeably. When you write your own template library, doing the same for a few most-common type combinations pays off immediately.
+
+::: warning extern template is not separate compilation
+One easy misconception: `extern template` lets you "not generate in this TU." It really does free the consuming TU from copying the full definition in — a declaration plus the `extern template` declaration is enough (the `tu_b` example above spells out the full definition, but that is redundant; drop the definition, keep only the declaration, and it still compiles and links). Its job, though, is still to cut redundant instantiation, not to truly separate declaration from definition. The instantiation point must still exist somewhere (explicitly or implicitly instantiated in some TU); `extern template` just lets other TUs reuse it. Clean separate compilation for templates, the way ordinary functions put declarations in `.h` and implementations in one `.cpp`, still has no clean answer today.
+:::
+
+## Function Templates Cannot Be Partially Specialized: The Classic Trap
+
+Here is the main event. Class templates can be partially specialized. Variable templates (since C++14) can be partially specialized. **Function templates cannot be.** This is not a quirk of some compiler; the standard says so explicitly. cppreference puts it plainly on the templates overview: partial specialization is only allowed for class templates and variable templates.
+
+Most people first hit this wall trying to write "a special version of a function template for pointer types." Intuitively, if a class template can do `template <typename T> class Foo<T*>`, a function template should be able to copy the pattern.
+
+```cpp
+template <typename T>
+T identity(T x) { return x; }
+
+// trying to partially specialize for T* -- compile error!
+template <typename T>
+T identity<T*>(T* x) { return *x; }
+```
+
+The compiler stops it on the spot.
+
+```text
+fn_partial.cpp:6:3: error: non-class, non-variable partial specialization
+      'identity<T*>' is not allowed
+    6 | T identity<T*>(T* x) { return *x; }
+      |   ^~~~~~~~~~~~
+```
+
+GCC's wording states the rule clearly: only partial specializations of classes and variables are allowed, not functions.
+
+Why does the standard say so? Because functions have **overloading**, and overloading already does everything partial specialization would want to do, more flexibly. Partial specialization is "provide a specialized version for some pattern of the template parameters." Overloading is "provide a separate function for some argument types." The two overlap, so the standard lets functions take the overloading path and skips bolting on a partial-specialization syntax that would fight it semantically.
+
+So how do you write a special version for pointers? Use an overload.
+
+```cpp
+template <typename T>
+T identity(T x) { return x; }            // general version
+
+// an overload that gives pointers a dedicated version
+template <typename T>
+T identity(T* x) { return *x; }          // pointer version
+
+int main() {
+    int v = 42;
+    identity(v);        // calls the T=int version, returns 42
+    identity(&v);       // calls the pointer overload, returns 42
+}
+```
+
+The second `identity` here is a new function template (parameter `T*`), not a partial specialization of the first. When `identity(&v)` is called, the compiler does overload resolution, the pointer version matches better, and it wins.
+
+When the branching gets more complex, say "pointers go this way, integers go that way, everything else is general," overloading works but gets verbose. There are two more modern tools for this, both covered in part two of this volume: `std::enable_if` with SFINAE (C++11), and `if constexpr` for compile-time branching (C++17). The former dispatches by "making a particular overload vanish from the candidate set when a condition fails," the latter just writes a compile-time `if` directly in the body. Here is a preview of `if constexpr`, to show how clean it can get.
+
+```cpp
+template <typename T>
+void process(T x) {
+    if constexpr (std::is_pointer_v<T>) {
+        std::cout << "pointer, dereferenced: " << *x << "\n";
+    } else if constexpr (std::is_integral_v<T>) {
+        std::cout << "integer: " << x << "\n";
+    } else {
+        std::cout << "other type\n";
+    }
+}
+```
+
+`if constexpr` discards the failing branches at compile time, so it never leaves behind a "dereference a non-pointer" compile error. This is the preferred way to handle "a function template walks different logic for different types" after C++17, dragging code that used to require convoluted SFINAE back into something a normal human can read.
+
+## Full Specialization Is Legal, but Use It in the Right Place
+
+We spent a while on no partial specialization. What about full specialization? **Full specialization of a function template is legal.** The syntax begins with `template<>`, with every template parameter pinned.
+
+```cpp
+template <typename T>
+const char* type_name() { return "unknown"; }
+
+// full specialization: int version
+template <>
+const char* type_name<int>() { return "int"; }
+
+// full specialization: double version
+template <>
+const char* type_name<double>() { return "double"; }
+```
+
+There is a trap to know about full specialization: it does **not** participate in the "template" path of overload resolution. It inserts itself into the candidate set as an ordinary function. That means the signature of a full specialization must exactly correspond to some instantiation of the primary template, with no slack. And once a full specialization exists, it pins down that specific version and no longer tracks the primary template.
+
+In practice, full specialization of function templates is not common. Most of the time, writing an ordinary overload (a non-template function) is less hassle than a full specialization, because overload rules are more intuitive. Full specialization fits better when you want to "preserve template identity, but customize the implementation for one type," for example specializing a function template for `const char*` to do string comparison.
+
+::: warning Do not trip ODR on full specialization
+The definition of a full specialization may appear in only one translation unit, otherwise it violates the one-definition rule (ODR). If you put a full specialization in a header that several `.cpp` files include, the linker reports a duplicate definition. The fix is either to put it in a single `.cpp`, or to mark it `inline`. Instantiations of the primary template do not have this problem (the linker merges duplicate instantiations), but a full specialization is an ordinary function and does not get that treatment.
+:::
+
+## What a Restrained Little Library Looks Like
+
+String the previous sections together and look at a typical layout when writing a library. Suppose we offer a `clamp` function template, and we want the common types to compile fast without giving up genericity.
+
+The header holds the template definition and declares `extern template` for the most common types.
+
+```cpp
+// clamp.h
+template <typename T>
+const T& clamp(const T& v, const T& lo, const T& hi) {
+    if (v < lo) return lo;
+    if (hi < v) return hi;
+    return v;
+}
+
+// pre-declare: int and double versions are instantiated elsewhere; TUs including this header should not generate them
+extern template const int&    clamp<int>(const int&, const int&, const int&);
+extern template const double& clamp<double>(const double&, const double&, const double&);
+```
+
+The source file provides explicit instantiation definitions for those types.
+
+```cpp
+// clamp.cpp
+#include "clamp.h"
+
+// actually emit the code here
+template const int&    clamp<int>(const int&, const int&, const int&);
+template const double& clamp<double>(const double&, const double&, const double&);
+```
+
+Now every TU that includes `clamp.h` and uses `clamp<int>` skips instantiating it and links to the copy in `clamp.cpp`. Other types (like `clamp<long>`) still instantiate implicitly per TU, because there is no `extern template` for them. Common types are saved; uncommon types are not blocked. This is the standard library's internal pattern, just at much larger scale.
+
+Next we move into class templates. Member functions of class templates have a "lazy instantiation" temper, and inside templates there is a split between dependent names and non-dependent names. Together, these two things make writing class templates a different experience from function templates.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md
new file mode 100644
index 000000000..7d7f72f65
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md
@@ -0,0 +1,256 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 'Class templates are the foundation of the STL. This piece covers the
+  three differences from function templates that trip people up: members defined inside
+  or outside the class, the lazy-instantiation temper, and why dependent names need
+  typename and this-> for disambiguation.'
+difficulty: intermediate
+order: 3
+platform: host
+prerequisites:
+- 'Templates, From Scratch: A Code Recipe with Placeholders'
+- 'Function Templates, In Depth: Compilation Model and the No-Partial-Specialization
+  Trap'
+reading_time_minutes: 10
+related:
+- 'Template Specialization and Partial Specialization: The Art of Pattern Matching'
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+---
+# Class Templates: Members, Dependent Names, and Lazy Instantiation
+
+Class templates are the foundation of the STL. `std::vector`, `std::map`, and `std::string` (really `std::basic_string<char>`) are all class templates. Knowing function templates does not mean knowing class templates. There are a few key differences, and they happen to be exactly where newcomers stumble. This piece focuses on three: whether member functions go inside or outside the class, the error-hiding temper that lazy instantiation brings, and why dependent names need `typename` and `this->` for disambiguation. Get these three straight, and writing your own containers or policy classes, or reading STL source, stops snagging on these details.
+
+## What a Class Template Looks Like
+
+Start from a minimal stack and look at things as we go.
+
+```cpp
+template <typename T>
+class Stack {
+public:
+    void push(const T& value) { data_.push_back(value); }
+    void pop() { data_.pop_back(); }
+    const T& top() const { return data_.back(); }
+    bool empty() const { return data_.empty(); }
+private:
+    std::vector<T> data_;   // use vector as the backing store
+};
+```
+
+`template <typename T>` tells the compiler this is a class template and `T` is a type parameter. Everywhere `T` appears, it gets substituted with the concrete type at instantiation. `Stack<int>` replaces every `T` with `int`, `Stack<std::string>` with `std::string`, and each produces a separate class.
+
+Writing all member functions inside the class, as above, is the most common style and the cleanest. Member functions can also be written outside the class, but the syntax has a trap covered in the next section.
+
+Member functions of a class template are themselves templates (more precisely, "templated functions"). Only when a member function is actually called does the compiler instantiate it for the current type. This leads into the most important temper of class templates.
+
+## Lazy Instantiation: No Use, No Pay
+
+Member functions of a class template are **instantiated only when actually used**. Writing `Stack<Heavy>` does not generate every member function of `Stack`, only the ones you call. The previous piece mentioned this; here is a blunter example.
+
+```cpp
+#include <iostream>
+
+template <typename T>
+struct Box {
+    T value;
+
+    void used_show() const {
+        std::cout << "value = " << value << "\n";
+    }
+
+    // The body refers to nonexistent_field, which does not exist on T.
+    // As long as nobody calls it, the compiler never instantiates it, so it never errors.
+    void unused_broken() const {
+        std::cout << value.nonexistent_field << "\n";
+    }
+};
+
+int main() {
+    Box<int> b{42};
+    b.used_show();   // only this one is used
+    return 0;
+}
+```
+
+`unused_broken` writes `value.nonexistent_field`, which for `T=int` is `int::nonexistent_field`, pure nonsense. Yet this compiles and runs fine.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 lazy_inst.cpp -o lazy_inst && ./lazy_inst
+value = 42
+```
+
+The reason is lazy instantiation. `main` only calls `used_show`, so the compiler instantiates only `Box<int>::used_show`. `unused_broken` is never used, the compiler never looks at it, and whatever nonsense is inside never errors.
+
+This is the STL's backbone. `std::vector` has dozens of member functions. If you only use `push_back` and `size`, the compiler instantiates only those, and `insert`, `erase`, and `emplace` are never generated. Otherwise every `vector<X>` would have to instantiate all its members, and compile time and binary size would balloon out of control.
+
+There is a flip side. Lazy instantiation means **errors hide deep**. Write a type error in some member function, and as long as no test case touches it, it never surfaces at compile time. When someone finally calls it, possibly much later and far away, tracking it down takes real effort. So when writing class templates, it is best to either run a "full self-check" that instantiates every member at least once, or write unit tests that cover every member. Recent GCC versions flag some of these by default with diagnostics in the template body.
+
+## Defining Members Outside the Class: Do Not Skip the Template Head
+
+When a member function is written outside the class, the syntax is a `template <...>` head plus a `ClassName<T>::` qualifier. Neither can be omitted.
+
+```cpp
+template <typename T>
+class Stack {
+public:
+    void push(const T& value);
+    const T& top() const;
+private:
+    std::vector<T> data_;
+};
+
+// out-of-class definition: needs the template head, and the class name needs <T>
+template <typename T>
+void Stack<T>::push(const T& value) {
+    data_.push_back(value);
+}
+
+template <typename T>
+const T& Stack<T>::top() const {
+    return data_.back();
+}
+```
+
+Two common traps. One is forgetting the `template <typename T>` head, so the compiler does not know where `T` in `Stack<T>` comes from. The other is forgetting `<T>` on the class name, writing `void Stack::push(...)`, which treats `Stack` as a concrete class when it is only a template name and needs `<T>` to refer to an instantiation.
+
+The upside of out-of-class definitions is a clean header. The downside is that the inclusion model still requires the definition to be visible at the use site, so out-of-class definitions usually still live in the header (or at the bottom of the same header file). This is still not the "declaration in .h, implementation in .cpp" of ordinary classes. Most small class templates put member functions inline in the class for simplicity. Large template libraries (STL implementations, for instance) split member functions out and place them in the same header or in a `.tpp` (template implementation) file that the header then includes.
+
+## Dependent vs Non-dependent Names: `typename` Disambiguation
+
+This is where class templates get confusing. Memorize two terms.
+
+A **non-dependent name** does not depend on any template parameter. Things like `int` and `std::cout`. The compiler knows what they are at the template definition point.
+
+A **dependent name** depends on some template parameter. Something like `T::value_type`, whose meaning is unknown until `T` is fixed.
+
+The trouble is with dependent names. When the compiler parses the template definition, it does not yet know what `T` is, so it cannot know whether `T::value_type` is a type, a static member variable, or something else. The C++ rule is: **do not assume it is a type by default.** If you want it used as a type, you must say so with the `typename` keyword.
+
+```cpp
+template <typename Container>
+void print_first(const Container& c) {
+    typename Container::value_type first = *c.begin();
+    std::cout << "first = " << first << "\n";
+}
+```
+
+`Container::value_type` here is used as a type (to declare a variable), so it needs `typename` in front. With it, the code compiles and runs.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 typename_dis.cpp -o typename_dis && ./typename_dis
+first = 10
+```
+
+Drop the `typename`, and GCC stops it, with an error message that states the rule clearly.
+
+```text
+typename_bad.cpp:3:5: error: need 'typename' before 'Container::value_type'
+      because 'Container' is a dependent scope
+    3 |     Container::value_type first = *c.begin();
+      |     ^~~~~~~~~~~
+```
+
+"`Container` is a dependent scope," so the compiler will not assume `value_type` is a type unless you say so.
+
+When do you need `typename`? Rule of thumb: when a dependent qualifier (a `::` involving a template parameter) appears in a position that needs a type (declaring a variable, a cast, a return type, a template type argument), add `typename`. C++20 relaxed this in a few spots: P0634 made `typename` optional in type-only contexts — type aliases (`using`), function return types, the type in a `new` expression, and data member declarations — but local variable declarations still need it. Building the habit of "dependent name used as a type, add typename" is the safest path and never wrong.
+
+There is a parallel `template` keyword for disambiguation. If a dependent name is followed by `<`, the compiler cannot tell whether this is a template or a less-than comparison, and you write `T::template Foo<int>()` to say that `Foo` is a template. This is rare, but you will know the tool exists when you hit it.
+
+## Dependent Base and `this->`
+
+Inheritance with class templates runs into a related trap. Look at this.
+
+```cpp
+template <typename T>
+struct Base {
+    void helper() {}
+    int data = 7;
+};
+
+template <typename T>
+struct Derived : Base<T> {
+    void call() {
+        helper();   // error!
+    }
+};
+```
+
+`Derived` inherits from `Base<T>`, and inside `Derived::call` it calls the base class `helper()`. Intuitively the base clearly has `helper`, so this should work. But the compiler errors.
+
+```text
+dep_base.cpp:10:9: error: there are no arguments to 'helper' that depend on
+      a template parameter, so a declaration of 'helper' must be available
+   10 |         helper();
+      |         ^~~~~~
+```
+
+The reason is the same logic as the `typename` case. `Base<T>` is a dependent base; its exact shape is unknown until `T` is fixed. When the compiler parses the definition of `Derived`, it does not look up non-dependent names (names without `T`, like `helper`) inside a dependent base, because for some specialization of `T`, `helper` might be a variable, or might not exist, and looking it up could produce a wrong answer.
+
+The fix is to make the name "carry dependence," most commonly with `this->`.
+
+```cpp
+template <typename T>
+struct Derived : Base<T> {
+    int fetch() { return this->data; }   // this-> makes the lookup enter the dependent base
+    void call() { this->helper(); }
+};
+
+int main() {
+    Derived<int> d;
+    d.call();
+    std::cout << "fetch() = " << d.fetch() << "\n";   // reaches Base<T>::data = 7
+}
+```
+
+`this->` tells the compiler "this is a member of the current object, look it up at instantiation time," and the problem goes away. It compiles and runs.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 dep_base_ok.cpp -o dep_base_ok && ./dep_base_ok
+fetch() = 7
+```
+
+An equivalent spelling is explicit qualification `Base<T>::helper()`, but that turns off virtual dispatch, so if `helper` is virtual, do not use `Base<T>::`, use `this->`. For ordinary cases both work, and `this->` is more general.
+
+This rule is two sides of the same coin as "two-phase lookup," covered in the next piece. Two-phase lookup requires the compiler to resolve non-dependent names at the template definition stage, while names inside a dependent base are not visible at that stage, so the compiler simply does not look there. Once you understand the motivation, `this->` stops feeling like "pointless syntactic noise." It exists to keep templates predictable under two-phase lookup.
+
+## Static Members: One per Type
+
+Class templates can have static data members. Unlike static members of ordinary classes, **each instantiation of a class template gets its own independent copy of a static member**.
+
+```cpp
+template <typename T>
+struct Counter {
+    static int instances;   // declaration
+};
+
+// definition (out of class): needs the template head
+template <typename T>
+int Counter<T>::instances = 0;
+
+// Counter<int>::instances and Counter<double>::instances are two different variables
+```
+
+`Counter<int>::instances` and `Counter<double>::instances` are two completely independent static variables that do not affect each other. This is often used to count instances per type or hold a per-type cache.
+
+Here is a trap to untangle. The out-of-class definition of a class template static member (`template <typename T> int Counter<T>::instances = 0;`) carries its own `template` head, which makes it a weak symbol. It **can** live in a header included by multiple translation units — the linker merges the copies automatically, with no ODR violation. It is only **non-template** static members (static members of an ordinary class) that are restricted to a single TU; putting those in a header included by multiple TUs does cause duplicate-definition errors. If the out-of-class definition feels like hassle, C++17 `inline` static members let you initialize in-class directly.
+
+```cpp
+template <typename T>
+struct Counter {
+    static inline int instances = 0;   // C++17: inline static member, in-class init, no out-of-class definition
+};
+```
+
+This is the modern form, which removes the hassle of out-of-class definitions.
+
+The next piece moves into specialization and partial specialization. Class templates can be partially specialized (unlike function templates), and the "pattern matching" semantics of partial specialization is the most expressive part of templates. The special implementation of `std::vector<bool>` and the entire machinery of type traits are all built on it.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md
new file mode 100644
index 000000000..52a1616b5
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md
@@ -0,0 +1,219 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 'Specialization is the most expressive part of templates. Full vs partial
+  specialization, the rule by which the compiler picks the most specialized version,
+  and two classic applications: why std::vector<bool> is a partial specialization,
+  and how the entire type_traits machinery (is_pointer, is_const) is built on partial
+  specialization.'
+difficulty: intermediate
+order: 4
+platform: host
+prerequisites:
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+- 'Function Templates, In Depth: Compilation Model and the No-Partial-Specialization
+  Trap'
+reading_time_minutes: 10
+related:
+- 'Non-Type Template Parameters: From Integers to C++20 Floats and Class Types'
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Template Specialization and Partial Specialization: The Art of Pattern Matching'
+---
+# Template Specialization and Partial Specialization: The Art of Pattern Matching
+
+The strongest part of templates is not "write one, fit any type." It is **giving some specific type, or some family of types, a separate, different implementation.** This mechanism is called specialization. It comes in two forms: full specialization targets one concrete type, partial specialization targets a family of types matching a pattern. The previous piece noted that function templates cannot be partially specialized; only class templates and variable templates can. This piece takes class-template specialization all the way: full specialization, partial specialization, the priority rule for which version the compiler picks, and two classic cases that push partial specialization to the limit, the standard library's `std::vector<bool>` and the whole of `<type_traits>`.
+
+## Full Specialization: A Separate Copy for One Concrete Type
+
+Full specialization provides a dedicated implementation for one **fully fixed** type. The syntax starts with `template<>`, with every template parameter pinned.
+
+```cpp
+// primary template
+template <typename T>
+struct TypeSize {
+    static constexpr std::size_t value = sizeof(T);
+};
+
+// full specialization: a dedicated version for int
+template <>
+struct TypeSize<int> {
+    static constexpr std::size_t value = 4;   // assume a 32-bit platform where int is 4 bytes
+};
+```
+
+With this specialization in place, `TypeSize<int>::value` takes the `4` from the specialization, while `TypeSize<double>::value` goes through the primary template and computes `sizeof(double)`. A full specialization "cuts in line": just as the compiler would instantiate `TypeSize<int>` from the primary template, it spots the existing full specialization and uses that instead, never generating the primary version.
+
+Two things to remember about full specialization. First, it **is no longer a template**; it is a concrete class (or function, or variable) with all template parameters fixed. This affects ODR: the definition of a full specialization may appear in only one translation unit, or it is a duplicate definition. Second, the signature of a full specialization must correspond exactly to some instantiation of the primary template, with no slack.
+
+## Partial Specialization: A Separate Copy for a Family of Types
+
+Partial specialization targets not one concrete type, but **a family of types matching a pattern**. The most common patterns are "pointer types" and "reference types." The syntax starts with `template <typename T>` (note it is still a template, with `T` unbound), and the class name is followed by a patterned form like `<T*>`.
+
+```cpp
+// primary template
+template <typename T>
+struct TypeKind {
+    static const char* name() { return "generic (primary)"; }
+};
+
+// partial specialization: pointer types
+template <typename T>
+struct TypeKind<T*> {
+    static const char* name() { return "pointer (partial)"; }
+};
+
+// partial specialization: lvalue reference types
+template <typename T>
+struct TypeKind<T&> {
+    static const char* name() { return "lvalue reference (partial)"; }
+};
+```
+
+Note the key difference from full specialization: the partial specialization's `template <typename T>` head still has a `T`, so it remains a template. A full specialization has an empty `template<>` with every parameter pinned. That difference is what lets a partial specialization match "a family of types" while a full specialization matches only "one type."
+
+Run it and see how it picks.
+
+```cpp
+int main() {
+    std::cout << "double      : " << TypeKind<double>::name() << "\n";
+    std::cout << "double*     : " << TypeKind<double*>::name() << "\n";
+    std::cout << "double&     : " << TypeKind<double&>::name() << "\n";
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 spec_test.cpp -o spec_test && ./spec_test
+double      : generic (primary)
+double*     : pointer (partial)
+double&     : lvalue reference (partial)
+```
+
+(The full specialization for `int*` is not defined yet, so `main` does not touch `int*` here. Once the next section adds the full specialization, we will see how `int*` is picked.)
+
+`double` matches no partial specialization and goes through the primary template. `double*` matches the `T*` partial. `double&` matches the `T&` partial. This is the core power of partial specialization: **dispatch different implementations based on the "shape" of a type**, like a compile-time type switch.
+
+## Priority: Full > Partial > Primary
+
+That `int*` line in the output deserves a closer look. `int*` matches both the `T*` partial (with `T=int`) and the following full specialization.
+
+```cpp
+// full specialization: specifically for int*
+template <>
+struct TypeKind<int*> {
+    static const char* name() { return "int* (full, wins over partial)"; }
+};
+```
+
+Both match. Which does the compiler pick? The rule is **pick the more specialized one**. A full specialization is more specialized than a partial (it has no unbound parameters), and a partial is more specialized than the primary. So the priority is: **full > partial > primary**. Add the full specialization above to the file, then have `main` also print `TypeKind<int*>::name()`, and the output for that line is `int* (full, wins over partial)` — `int*` hits the full specialization rather than the `T*` partial.
+
+When several partial specializations all match, things get subtler, and the compiler compares which one is "more specific." Between `T*` and `T const*` partials, for `const int*`, `T const*` is more specific and wins. The "more specialized" judgment has formal rules; in everyday code, remember "the compiler picks the tightest fit." If there is genuine ambiguity, the compiler reports it and you adjust the patterns.
+
+## What Patterns Partial Specialization Can Match
+
+The expressiveness of partial specialization comes from the rich set of patterns it can match. Common ones include:
+
+- `T*`: pointer types
+- `T&` / `T&&`: reference types
+- `const T*`, `volatile T`: cv-qualified variants
+- `T[N]`: array types
+- `Foo<T>`, `Bar<T, U>`: instantiations of a specific template
+- even template template parameters can participate in pattern matching
+
+Combined, partial specialization can recognize almost any "type shape." This is what gives `<type_traits>` its many type queries, as we will see next.
+
+## Classic Application One: The std::vector\<bool\> Specialization
+
+The most famous partial specialization in the standard library is `std::vector<bool>`. It is not the ordinary version of `std::vector<T>` instantiated with `T=bool`. It is a specialization the library writes on purpose, so that one `bool` takes one bit instead of one byte, saving memory.
+
+```cpp
+// roughly what the standard library does (simplified)
+template <typename T, typename Alloc = std::allocator<T>>
+class vector { /* ordinary implementation, one T per slot */ };
+
+template <typename Alloc>
+class vector<bool, Alloc> { /* specialization: bit-packed, one bool per bit */ };
+```
+
+The `vector<bool>` specialization has a visible side effect: its `operator[]` does not return `bool&`. It returns a **proxy object** of type `std::vector<bool>::reference`. The reason is that once bits are packed, you cannot return "a reference to one bit" (the smallest addressable unit of memory is a byte), so it returns a temporary that mimics the behavior of `bool&`. You can see the difference directly.
+
+```cpp
+#include <iostream>
+#include <type_traits>
+#include <vector>
+
+int main() {
+    std::cout << std::boolalpha;
+    // vector<bool>'s reference is a proxy, not bool&
+    std::cout << "vector<bool>::reference is bool&?   "
+              << std::is_same_v<std::vector<bool>::reference, bool&> << "\n";
+    // an ordinary vector's reference is a real element reference
+    std::cout << "vector<char>::reference is char&?  "
+              << std::is_same_v<std::vector<char>::reference, char&> << "\n";
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 vecbool.cpp -o vecbool && ./vecbool
+vector<bool>::reference is bool&?   false
+vector<char>::reference is char&?  true
+```
+
+This proxy `reference` has caused `vector<bool>` no end of controversy. It makes `vector<bool>` not fully satisfy the "sequence container" requirements (because `reference` is not a real element reference), and it makes some generic code behave oddly on it. `auto& x = vec[0];` on `vector<bool>` **does not compile at all** — the proxy `reference` is an rvalue temporary, and an rvalue cannot bind to a non-const lvalue reference. Even switching to `auto x = vec[0];` does not give you a `bool`; it gives you the proxy object, and some operations on it behave unexpectedly. The committee has debated whether to pull it out of the standard and replace it with something like `dynamic_bitset`, but since it is used everywhere, the cost of changing it is too high, and it has stayed. It is a cautionary tale about partial specialization: a specialization can completely redefine the implementation, but the cost is that it may no longer satisfy the interface contract the primary template implies, and users trip over it.
+
+## Classic Application Two: The Whole type_traits Pattern
+
+The queries in `<type_traits>` like `std::is_pointer`, `std::is_const`, and `std::is_reference` are all built on the same pattern underneath: "primary template returns false, partial specialization that matches returns true." Hand-write an `is_pointer` and the secret is out.
+
+```cpp
+// primary template: default to "not a pointer"
+template <typename T>
+struct is_pointer {
+    static constexpr bool value = false;
+};
+
+// partial specialization: only pointer types match
+template <typename T>
+struct is_pointer<T*> {
+    static constexpr bool value = true;
+};
+```
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 is_ptr.cpp -o is_ptr && ./is_ptr
+is_pointer<int>::value       = false
+is_pointer<int*>::value      = true
+is_pointer<int**>::value     = true
+is_pointer<int&>::value      = false
+```
+
+`int` goes through the primary template, `value=false`. `int*` hits the `T*` partial, `value=true`. `int**` also hits it (with `T=int*`). `int&` is a reference, not a pointer, so it goes through the primary template and returns `false`.
+
+That is the entire secret of `std::is_pointer`. The standard library version has a bit more (it also handles pointers to members, cv-qualification, and edge cases), but the core idea is exactly this primary-plus-partial pattern. `is_const` (where `const T*` does not count but `T const` does), `is_reference` (`T&` and `T&&`), `is_array` (`T[N]`) all use the same approach: a primary template with a default value, and a partial specialization that overrides it for the target pattern.
+
+Once this pattern clicks, you can write your own type queries. To check "is it a function pointer," write a primary template that defaults to false and a partial specialization for `R(*)(Args...)` that returns true. The entire `<type_traits>` is a few hundred such partial specializations stacked together. Part two of this volume covers SFINAE, and part three covers concepts, and both build on understanding "compile-time type judgment through partial specialization."
+
+## A Few Limits of Partial Specialization
+
+Finally, nail down the boundaries of partial specialization so you do not trip over them.
+
+**Function templates cannot be partially specialized.** Covered in the previous piece. The standard allows partial specialization only for class templates and variable templates (since C++14). For function dispatch, use overloading, `if constexpr`, or SFINAE.
+
+**Partial specialization usually lives at namespace scope.** The vast majority of partial specializations are written at namespace level. Since C++11 (CWG 727), a partial specialization of a member class template may also appear in the scope of the enclosing class, but the syntax is awkward and rarely used. For peace of mind, just put partial specializations at namespace scope.
+
+**A partial specialization can completely redefine the implementation.** It does not need to have the same members as the primary template; it can look entirely different. But that also means anyone accessing it through the primary template's name must make sure the specialization provides the corresponding members, or the code fails to compile for that type. `vector<bool>` does exactly this, with members that are almost the same as an ordinary `vector` but with subtle semantic differences.
+
+**ODR differs between partial and full specialization.** A partial specialization is still a template, and its instantiations across translation units merge automatically without violating ODR. A full specialization is a concrete entity, so its definition may appear in only one translation unit, or it must be marked `inline`.
+
+Next we move into non-type template parameters. They are an important actor in partial-specialization pattern matching, the `N` in `std::array<T, N>` is one, and C++20 loosened the rules for what a non-type parameter can be, expanding from integers and pointers to floating-point values and class types that meet certain conditions.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md
new file mode 100644
index 000000000..246e74c0f
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md
@@ -0,0 +1,193 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: A non-type template parameter parameterizes a value, not a type. The
+  N in array<T, N> is one. What types it accepts, the C++17 auto placeholder, how
+  C++20 opened it up to floating-point and structural class types, and which arguments
+  count as the same instantiation.
+difficulty: intermediate
+order: 5
+platform: host
+prerequisites:
+- 'Template Specialization and Partial Specialization: The Art of Pattern Matching'
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+reading_time_minutes: 9
+related:
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+- 'Template Friends and Barton-Nackman: The Hidden Friends Trick'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+- 编译期计算
+title: 'Non-Type Template Parameters: From Integers to C++20 Floats and Class Types'
+---
+# Non-Type Template Parameters: From Integers to C++20 Floats and Class Types
+
+The previous pieces parameterized types. `typename T` stands in for a type. A template can also parameterize something else: **a value known at compile time**. The `N` in `std::array<T, N>` and `std::bitset<N>` is exactly this kind of parameter, called a non-type template parameter. This piece covers what types of values it can take, how C++17 `auto` made it more flexible, how C++20 opened it up from "integers and pointers only" to "floating-point and even class types," and which arguments count as the "same" instantiation. The C++20 relaxation is the biggest upgrade non-type parameters have had since they were invented, and it enables fixed_string, compile-time constant objects, and other new tricks.
+
+## What a Non-Type Parameter Is: Parameterizing a Value
+
+A type parameter `typename T` stands in for a type. A non-type parameter stands in for **a concrete value**. The most classic form is an integer.
+
+```cpp
+template <typename T, std::size_t N>
+struct array {
+    T data[N];   // N is a size known at compile time
+};
+```
+
+Here `N` is a non-type parameter. Its "type" is `std::size_t`, and at instantiation you give it a concrete value, say `array<int, 8>`, so `N` is 8. `N` must be known at compile time, because the compiler uses it to produce the array type `int data[8]`, which is part of the type itself and cannot change at runtime.
+
+What types can a non-type parameter take? Before C++17, the rules were narrow: integer types (the various `int`, `char`, `bool`), enumerations, pointers, references, and pointers to members. Floating-point was out. Ordinary class objects were out. The restrictions spawned a pile of workarounds, and C++20 finally legitimized them.
+
+## Integers and Pointers: The Classic Uses
+
+Integer non-type parameters are the most common. Fixed-size containers, bitsets, and compile-time constants all rely on them.
+
+```cpp
+template <int Lower, int Upper>
+struct Range {
+    static constexpr int lo = Lower;
+    static constexpr int hi = Upper;
+};
+
+// arguments must be compile-time constants
+constexpr int kMin = 10;
+Range<kMin, kMin + 100> r;   // OK: both arguments are constant expressions
+// Range<some_runtime_value, 100> r2;   // compile error: argument not constant
+```
+
+Pointers and references can also be non-type parameters, but the argument must be an object whose address is known at compile time, such as the address of a static variable or a function.
+
+```cpp
+template <int* P>
+struct PtrHolder {
+    static int* get() { return P; }
+};
+
+int global_var = 42;
+PtrHolder<&global_var> ph;   // OK: the global's address is known at compile time
+```
+
+This "argument must be a constant expression" requirement is the fundamental difference between a non-type parameter and an ordinary function parameter. A function parameter takes a value at runtime; a non-type parameter has to be fixed at compile time.
+
+## C++17 auto: Letting the Type Be Deduced
+
+C++17 added something practical for non-type parameters: the `auto` placeholder. You used to have to spell out the type, `template <int N>`. Now you can write `template <auto N>` and let the compiler deduce it from the argument.
+
+```cpp
+template <auto N>
+struct Constant {
+    static constexpr auto value = N;
+};
+```
+
+Run it to see the flexibility.
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 ntp_auto.cpp -o ntp_auto && ./ntp_auto
+Constant<42>::value = 42
+Constant<true>::value = 1
+Constant<'a'>::value = a
+```
+
+`Constant<42>` deduces `N` as `int`, `Constant<true>` as `bool`, `Constant<'a'>` as `char`. One template parameter holds values of different types. This removes a lot of `template <typename T, T N>` boilerplate when writing generic metaprogramming. You used to need two parameters (a type plus a value); now one `auto` does it.
+
+## C++20's Two Big Openings: Floating-Point and Class Types
+
+C++20 did major surgery on non-type parameters and opened two areas that were off-limits before.
+
+**Floating-point.** Before C++20, floating-point could not be a non-type parameter, because equivalence was hard to define cleanly (whether two compile-time floats are "equal" is tricky). C++20 nailed the rule down and opened it up.
+
+```cpp
+template <double Pi>
+struct CircleArea {
+    static constexpr double compute(double r) { return Pi * r * r; }
+};
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_float.cpp -o ntp_float && ./ntp_float
+area(2.0) = 12.5664
+```
+
+`CircleArea<3.14159265>` bakes pi into the type as a compile-time constant. You used to need an ordinary `constexpr double pi = ...` variable for this. Now it can go straight into a template parameter, which means different values of `Pi` produce different types, so the type itself can carry precision information.
+
+**Class types (structural class).** This is the more imaginative half of the C++20 relaxation. Class objects used to be barred from non-type parameters because they have constructors, addresses, and lifetimes, and cannot be compared for equivalence easily. C++20 introduced the notion of a **structural type**: a class type that meets a few conditions can be used as a non-type parameter. The conditions are that it is a **literal class type** (a literal class — having a constexpr constructor is enough, it does **not** have to be an aggregate), that all bases and non-static data members are `public` and non-`mutable`, and that the bases and members are themselves structural. In short, an "all-public, member-immutable value type" whose equivalence the compiler can decide by comparing members one by one.
+
+One easy point to confuse: a literal class is not the same thing as an aggregate. An aggregate forbids user-declared constructors; a literal class only requires a constexpr constructor (and may have user-provided constructors). What structural asks for is a literal class, so **a class with a constexpr constructor — even if it is not an aggregate — can be a non-type parameter**. The `fixed_string` in the next paragraph is exactly this case: it has a constexpr constructor that copies a `char` array, it is not an aggregate, but it is structural.
+
+```cpp
+struct Point {      // structural: public, non-mutable, members all structural (int); also a literal class
+    int x;
+    int y;
+};
+
+template <Point P>
+struct Pixel {
+    static constexpr Point pos = P;
+};
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_struct.cpp -o ntp_struct && ./ntp_struct
+origin: (0,0)
+corner: (3,4)
+```
+
+`Pixel<Point{3, 4}>` bakes a 2D coordinate into the type. The flagship application of this is **fixed_string**: using a structural string class (with a constexpr constructor and a `char` array inside), you can wrap a string into a type and get "a type that carries a string." Logging libraries that tag each level with a fixed_string, or networking libraries that put URL paths into types, build on this. Note that string literals can **never** be a non-type parameter directly (this is still true in C++20): the type of a literal is `const char[N]`, which decays to a pointer, and different literals have different addresses, so equivalence cannot be handled. The C++20 breakthrough is not "literals as NTTP" — it is "wrap the literal in a structural fixed_string class and use that as the NTTP."
+
+## Equivalence: Which Arguments Count as "the Same"
+
+Non-type parameters come with an unavoidable question: when do two arguments count as the "same instantiation"? The rule is called template-argument-equivalent. For integers, it is value equality: `1 + 1` and `2` are equivalent, so `Tag<1 + 1>` and `Tag<2>` are the same type.
+
+```cpp
+#include <iostream>
+#include <type_traits>
+
+template <int N>
+struct Tag {};
+
+int main() {
+    std::cout << std::boolalpha;
+    std::cout << "Tag<1+1> is Tag<2>? " << std::is_same_v<Tag<1 + 1>, Tag<2>> << "\n";
+    std::cout << "Tag<2*3> is Tag<6>? " << std::is_same_v<Tag<2 * 3>, Tag<6>> << "\n";
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_equiv.cpp -o ntp_equiv && ./ntp_equiv
+Tag<1+1> is Tag<2>? true
+Tag<2*3> is Tag<6>? true
+```
+
+The program prints `true`, which confirms `Tag<1+1>` and `Tag<2>` are the same type. The practical effect: whether you write `1+1` or `2`, the compiler does not instantiate `Tag<2>` twice, because it recognizes them as the same thing.
+
+For pointers and references, equivalence is "points to the same object or function." For floating-point (C++20) and structural class types (C++20), equivalence is a bitwise or member-wise comparison. One thing to watch with floating-point: two float arguments count as equivalent only when they are bitwise identical, not when they are numerically equal. The classic counterexample is `Circle<0.0>` versus `Circle<-0.0>`: `0.0 == -0.0` holds numerically, but the bit patterns differ (the sign bit differs), so they are **two different types**. Conversely, `Circle<3.14>` and `Circle<3.14000>` end up bitwise identical after lexical folding, so they are the same type. This avoids ambiguity from precision fuzz, and it also means when you pass a floating-point template argument, the literal has to be exact.
+
+## Typical Uses of Non-Type Parameters
+
+Grouping the common uses, so you know which to reach for.
+
+Fixed-size containers. `std::array<T, N>`, `std::bitset<N>`, and the `fixed_vector<T, N>` project at the end of this volume all use integer non-type parameters to bake the size into the type. The payoff is stack storage, no dynamic allocation, and type-safe sizes (different `N` give different `array` types, and the compiler catches misuse).
+
+Compile-time constants. Bake physical constants, configuration values, or version numbers into types as non-type parameters. `CircleArea<3.14>` in this piece is that kind. The type carries the value, which enables compile-time dispatch.
+
+Strings and objects after C++20. fixed_string, compile-time coordinates, compile-time configuration objects all rely on structural class non-type parameters. This is a new window C++20 opened for template metaprogramming, and part three of this volume expands on it.
+
+## A Few Traps
+
+The argument must be a constant expression. This is the rule; runtime values do not compile.
+
+String literals can never be a non-type parameter directly (this is still true in C++20). `Foo<"hello">` does not work, because after decay the equivalence cannot be handled. The C++20 fix is to wrap the literal in a structural fixed_string class, covered in part three.
+
+Floating-point equivalence is bitwise. `Circle<0.0>` and `Circle<-0.0>` are numerically equal but bitwise different, so they are two types; in the other direction, `Circle<3.14>` and `Circle<3.14000>` are bitwise identical after lexical folding, so they are the same type. The criterion is bitwise, not numerical, not syntactic.
+
+Next we move into two-phase name lookup and ADL. Name lookup inside templates works nothing like ordinary code; it happens in two phases, and that mechanism is exactly what explains why the `typename`, `this->`, and hidden-friends rules from the previous pieces have to exist.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md
new file mode 100644
index 000000000..847fc4947
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md
@@ -0,0 +1,168 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: Name lookup inside templates works nothing like ordinary code. It happens
+  in two phases. This piece covers two-phase lookup, dependent vs non-dependent names,
+  ADL (argument-dependent lookup), and why the typename, this->, and hidden-friends
+  rules from earlier pieces have to exist.
+difficulty: intermediate
+order: 6
+platform: host
+prerequisites:
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+- 'Non-Type Template Parameters: From Integers to C++20 Floats and Class Types'
+reading_time_minutes: 9
+related:
+- 'Template Friends and Barton-Nackman: The Hidden Friends Trick'
+- 'Template Specialization and Partial Specialization: The Art of Pattern Matching'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Name Lookup and ADL: How Two-Phase Lookup Works'
+---
+# Name Lookup and ADL: How Two-Phase Lookup Works
+
+In ordinary code, when you use a name, the compiler looks it up at the current position, finds it, and uses it. In templates, that stops working. Name lookup in templates happens in two phases, one at the template definition and one at instantiation. This mechanism is called two-phase lookup, and it is exactly what explains the seemingly strange rules from earlier pieces: why `typename` cannot be dropped, why `this->` is mandatory, and why hidden friends matter. This piece takes two-phase lookup, dependent and non-dependent names, and ADL all the way through. After it, the "inexplicable" errors you hit in templates will all trace back to a root cause you can name.
+
+## Name Lookup in Ordinary Code: All at Once
+
+Start with ordinary functions. In an ordinary function, when you use a name, the compiler does ordinary lookup at the definition point, walking outward through namespaces until it finds a candidate set and stops.
+
+```cpp
+void helper(int) {}
+
+void caller() {
+    helper(42);   // the compiler looks up helper at caller's definition point and finds ::helper(int)
+}
+```
+
+This is intuitive. Ordinary lookup only sees names visible "before the definition point." Same-name functions declared later do not count.
+
+## Templates Are Different: Two Phases
+
+Templates split this into two phases.
+
+**Phase one** (template definition): when the compiler parses the template definition, it looks up and binds all **non-dependent names**. At this point `T` is unknown, so names that depend on `T` cannot be looked up yet, and they are set aside.
+
+**Phase two** (template instantiation): when the template is instantiated with a concrete type, `T` is fixed, and the compiler looks up **dependent names**. The main tool at this phase is ADL (argument-dependent lookup).
+
+Why two phases? Because at the template definition, the compiler has no idea what `T` will be. It cannot know whether `T::value_type` is a type or a variable, or which namespace `foo` in `foo(t)` should be searched. So it resolves what it can (non-dependent names) now, and defers what it cannot (dependent names) to instantiation.
+
+Here is a classic example that shows two-phase lookup in action.
+
+```cpp
+#include <iostream>
+
+// helper exists before the template definition
+void helper(int) { std::cout << "::helper(int), defined before template\n"; }
+
+template <typename T>
+void call_it(T x) {
+    helper(x);   // helper is non-dependent, looked up and bound in phase one (definition point)
+}
+
+// helper added after the template definition
+void helper(double) { std::cout << "::helper(double), defined after template\n"; }
+
+int main() {
+    call_it(3.14);   // T=double. Intuitively, would you expect helper(double)?
+    return 0;
+}
+```
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 twophase.cpp -o twophase && ./twophase
+::helper(int), defined before template
+```
+
+`call_it(3.14)` actually goes to `helper(int)`, not to `helper(double)` defined later. The reason is two-phase lookup. The name `helper` is non-dependent (it carries no `T`), so it is looked up and bound in phase one, at the template definition, to the only `helper` visible then, `helper(int)`. The `helper(double)` defined after the template is invisible in phase one. Phase two only does ADL for dependent names, and `double` is a builtin with no associated namespace, so ADL adds nothing. So `helper(x)` is bound to `helper(int)` for good, and `3.14` is truncated to `3`.
+
+Note that there is actually no difference from an ordinary function here: non-dependent names are looked up at the "definition point" regardless of whether `call_it` is a template or an ordinary function. As long as it is defined before `helper(double)`, it can only see `helper(int)`. Where two-phase lookup genuinely diverges from ordinary functions is the second phase for dependent names — in the next section, on ADL, we will see templates use the argument type at the instantiation point to find functions the definition point cannot see at all. That is two-phase lookup's real specialty.
+
+## Dependent vs Non-dependent Names
+
+This line decides which phase a name is looked up in, and deserves emphasis.
+
+A non-dependent name carries no template parameter. Things like `helper`, `std::cout`, `int`. They are looked up in phase one.
+
+A dependent name depends on some template parameter, directly or indirectly. Things like `T::value_type`, `x.foo()` (when the type of `x` is `T`), `foo(t)` (when the type of `t` depends on `T`). They are looked up in phase two, mainly via ADL.
+
+Whether a call `foo(t)` is dependent depends on whether the type of `t` depends on `T`. If `t` is of type `T`, then `foo(t)` is a dependent call, and phase two will look for `foo` in the namespace where `T` lives via ADL. That is the entry point where ADL does its work.
+
+## typename and this->: Direct Consequences of Two-Phase Lookup
+
+Looking back at two rules from earlier pieces, both are direct consequences of two-phase lookup.
+
+The `typename` disambiguation. For a dependent name like `T::value_type`, the compiler does not know what `T` is at phase one, so it cannot assume `value_type` is a type. It defaults to treating a dependent qualified name as a variable or function, unless you use `typename` to say explicitly "this is a type." This is the inevitable result of phase one being unable to resolve it at the definition point.
+
+`this->` for dependent-base members. When the base is `Base<T>`, its members are invisible at phase one too (because the shape of `Base<T>` depends on `T`). The compiler does not look up non-dependent names inside a dependent base at phase one, so a bare `helper()` cannot find the base's `helper`, and you need `this->helper()` to push the lookup to phase two (at instantiation, the type of `this` is known, and the base members are visible).
+
+Once you see that both rules come from two-phase lookup, they stop feeling like "pointless syntax." They are the mechanism that keeps template behavior predictable. Without two-phase lookup, lookup results would swing wildly with the context at the instantiation point, and nobody could write a reliable template library.
+
+## ADL: Argument-Dependent Lookup
+
+ADL (argument-dependent lookup) is the core tool phase two uses to look up dependent names. The rule is plain: **when calling a function, besides ordinary lookup, the compiler also looks for candidates in the namespaces of the argument types.**
+
+```cpp
+#include <iostream>
+
+namespace geo {
+    struct Point { int x; int y; };
+    void draw(const Point&) { std::cout << "geo::draw(Point)\n"; }
+}
+
+int main() {
+    geo::Point p{1, 2};
+    draw(p);   // no geo:: qualifier, no using namespace geo
+    return 0;
+}
+```
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 adl.cpp -o adl && ./adl
+geo::draw(Point)
+```
+
+`main` calls `draw(p)` with no `geo::` qualifier and no `using namespace geo`. Ordinary lookup does not find `draw` in the global namespace, so this should error. But ADL kicks in. The type of `p` is `geo::Point`, which lives in namespace `geo`, so the compiler looks for `draw` in `geo` and finds `geo::draw`. The call succeeds.
+
+ADL is also called Koenig lookup, after Andrew Koenig, who proposed it. The motivation is that functions operating on a type usually live in the namespace of that type. `std::cout << x` works because ADL looks for `operator<<` in the namespace of `x`'s type. Without ADL, you would need full qualification every time, and generic code would be impossible to write.
+
+## Why ADL Matters in Practice: Operators and Generic Algorithms
+
+ADL is not decorative. It underpins several key C++ idioms.
+
+**Operator lookup.** `std::cout << myObj` finds the `operator<<` for `myObj`'s type because of ADL. Whichever namespace the type of `myObj` lives in, ADL searches there for `operator<<`. This is the root reason overloaded operators work across namespaces.
+
+**The swap idiom.** Swapping two values in generic code uses the standard pattern.
+
+```cpp
+using std::swap;
+swap(a, b);   // not std::swap(a, b), but first using std::swap then a bare call
+```
+
+`using std::swap` pulls `std::swap` into the candidate set, then a bare `swap(a, b)` is called. If the type of `a` provides a more efficient `swap` in some namespace (say `ns::swap`), ADL finds it and prefers it. If not, it falls back to `std::swap`. That is why the standard library writes `using std::swap; swap(a, b);` everywhere instead of `std::swap(a, b)` directly, to leave room for custom types to optimize. `std::begin`, `std::end`, `std::size`, and `std::data` follow the same idea.
+
+**Designing for discoverability.** If you want a function to be found by generic algorithms, put it in the namespace of the argument type, and ADL discovers it automatically. This is a big part of C++ namespace design: functions travel with the types they operate on, instead of scattering globally.
+
+## Pitfalls and Compiler Differences in Two-Phase Lookup
+
+Two-phase lookup has a few traps, plus historical baggage, worth mentioning.
+
+**"Overloads added after the definition point are invisible."** The earlier `helper` example is this trap. A same-name overload declared after the template definition is invisible to non-dependent calls inside the template. The fix is either to move the overload declaration before the template, or to make the call dependent (so ADL can kick in).
+
+**MSVC's historical baggage.** For a long time, MSVC **did not strictly implement two-phase lookup**. It deferred all lookup to instantiation and did it in one pass. This meant some code that violated two-phase rules (and errored on GCC and Clang) compiled on MSVC, and the reverse too. This "MSVC accepts it, others break" or "others accept it, MSVC breaks" divergence is a classic pain in cross-platform template libraries. MSVC later added the `/permissive-` switch to follow two-phase lookup strictly, and modern projects turn it on, but old code still carries the traps.
+
+**ADL surprises.** ADL sometimes finds a function you did not expect. If a type happens to live in a namespace with a same-name function, ADL may pull it in and cause ambiguity or call the wrong implementation. Hidden friends (covered in the next piece) are the cure: define an operator as a hidden friend of the class, so it is only discovered by ADL when the arguments match exactly, without polluting the global overload pool.
+
+Next we move into template friends and the Barton-Nackman trick. Hidden friends, and friend injection inside the curiously-recurring-template pattern, only become clear once you understand ADL.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md
new file mode 100644
index 000000000..f679bbc40
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md
@@ -0,0 +1,189 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 'The previous piece covered ADL. This one covers its most elegant partner:
+  hidden friends and the Barton-Nackman trick. Define operator== as a friend inside
+  a class template, and each instantiation gets an operator dedicated to its own type,
+  without polluting the global overload pool, discoverable by ADL on exact match.'
+difficulty: intermediate
+order: 7
+platform: host
+prerequisites:
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+reading_time_minutes: 7
+related:
+- 'Alias Templates and using Declarations: Short Names for Types'
+- 'CRTP: Static Polymorphism with the Curiously Recurring Template Pattern'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 'Template Friends and Barton-Nackman: The Hidden Friends Trick'
+---
+# Template Friends and Barton-Nackman: The Hidden Friends Trick
+
+The previous piece covered ADL. This one covers its most elegant partner: **hidden friends** and the **Barton-Nackman trick**. The core idea in one sentence: define operators (like `operator==`, `operator<<`) as **friends of a class template, with the definition directly inside the class**. Each instantiation then gets a non-template operator function dedicated to that type. It neither pollutes the global overload pool, and it is discoverable by ADL on exact type match. This is the recommended way to give operators to a custom type in modern C++, and the standard library uses it heavily.
+
+## Friends: A Quick Review
+
+A friend is C++'s way of granting an external function or class access to a class's private members. A friend is not a member; it is an external entity that is simply allowed to touch the private parts.
+
+```cpp
+class Account {
+    int balance_;
+    friend void audit(const Account&);   // audit is not a member, but it can read balance_
+public:
+    explicit Account(int b) : balance_(b) {}
+};
+
+void audit(const Account& a) {
+    std::cout << "balance = " << a.balance_ << "\n";   // can read private, because it is a friend
+}
+```
+
+An ordinary friend is "declared in the class, defined outside." Template friends add new tricks on top, which we build up step by step.
+
+## Friend Injection: Defining a Friend Inside a Class Template
+
+Here is the key step. A friend can be more than declared in the class and defined outside. It can be **defined directly inside the class.** When that class is a template, the friend defined inside it is generated, for each concrete type, as a standalone function as the class is instantiated. That function has a special property: **it is not visible at namespace scope, and is only discoverable through ADL.**
+
+```cpp
+template <typename T>
+class Box {
+    T v_;
+public:
+    constexpr Box(T v) : v_(v) {}
+
+    // in-class friend definition: not a function template, but "a non-template function generated as Box<T> is instantiated"
+    friend constexpr bool operator==(const Box& a, const Box& b) {
+        return a.v_ == b.v_;
+    }
+};
+```
+
+Note that `operator==` here has no `template <...>` head of its own. It is written inside the `Box` class, and its parameter type uses `const Box&` (inside the class, `Box` is shorthand for `Box<T>`). When the compiler instantiates `Box<int>`, it generates a concrete function `bool operator==(const Box<int>&, const Box<int>&)`. When it instantiates `Box<double>`, it generates a different one, `bool operator==(const Box<double>&, ...)`. The two are distinct, each minding its own type.
+
+This technique is the **Barton-Nackman trick**, named after John Barton and Lee Nackman, who systematized it in their 1994 book "Scientific and Engineering C++". The core problem it solves: give a class template operators automatically, without writing a specialization for every type.
+
+## A Complete Example: == and <<
+
+Here is a runnable complete example, giving `Box<T>` both `==` and `<<`.
+
+```cpp
+#include <iostream>
+
+template <typename T>
+class Box {
+    T v_;
+public:
+    constexpr Box(T v) : v_(v) {}
+
+    friend constexpr bool operator==(const Box& a, const Box& b) {
+        return a.v_ == b.v_;
+    }
+    friend std::ostream& operator<<(std::ostream& os, const Box& b) {
+        return os << "Box{" << b.v_ << "}";
+    }
+};
+
+int main() {
+    Box<int> x{1}, y{1}, z{2};
+    Box<double> p{1.5}, q{1.5};
+    std::cout << std::boolalpha;
+    std::cout << "x == y: " << (x == y) << "\n";   // true
+    std::cout << "x == z: " << (x == z) << "\n";   // false
+    std::cout << "p == q: " << (p == q) << "\n";   // true (Box<double>'s own operator==)
+    std::cout << x << "\n";                        // Box{1}, ADL finds operator<<
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 barton.cpp -o barton && ./barton
+x == y: true
+x == z: false
+p == q: true
+Box{1}
+```
+
+`Box<int>` and `Box<double>` each have their own `operator==`. Comparing `x == y` goes through the `Box<int>` version, comparing `p == q` through the `Box<double>` version. `std::cout << x` works because `operator<<` is a hidden friend of `Box<int>`, and ADL discovers it through the type of `x`. You wrote neither `std::operator<<` nor a `using namespace`; it is all ADL.
+
+## The Power of Hidden Friends: No Global Overload Pollution
+
+The real value of hidden friends shows when you compare with the older "function-template operator== at namespace scope." The old style looks like this.
+
+```cpp
+// old style: define an operator== template at namespace scope
+// (this assumes Box exposes a public value(); the Box in this piece keeps v_
+//  private, so the old style would need either a public accessor on Box or
+//  this operator== also declared as a friend)
+template <typename T>
+bool operator==(const Box<T>& a, const Box<T>& b) {
+    return a.value() == b.value();
+}
+```
+
+This `operator==` is a **function template** living at namespace scope, participating as a candidate for every `Box<T>` comparison. The problem is that it participates in overload resolution for **every** `==` expression where the argument types are even tangentially related. This causes two troubles. First, slow compiles, since for every `==` the compiler has to consider whether this template applies. Second, ambiguity risk, if another namespace also has an `operator==` template, both might match and produce ambiguity.
+
+Hidden friends fix both. It is not a function template, but a concrete function generated on instantiation. It is not visible at namespace scope. Only when the argument types of `==` exactly match `Box<T>` does ADL pull it into the candidate set. Put differently, it appears "only when it should," and is otherwise completely transparent. This makes overload resolution faster and avoids accidental matches between unrelated types.
+
+::: warning Hidden friends not crossing types is a feature, not a bug
+
+A hidden friend is discovered only when argument types match exactly. `Box<int>`'s `operator==` takes only `Box<int>`, never `Box<double>`. So the following line fails to compile.
+
+```cpp
+Box<int> x{1};
+Box<double> p{1.5};
+bool same = (x == p);   // error: Box<int> and Box<double> have no common operator==
+```
+
+```text
+barton_bad.cpp:12:20: error: no match for 'operator=='
+      (operand types are 'Box<int>' and 'Box<double>')
+```
+
+This is the safety of hidden friends. If you genuinely want `Box<int>` to compare to `Box<double>`, you write a cross-type operator explicitly, rather than hoping it "just happens." Hidden friends make type relationships explicit, which is exactly why they are recommended.
+
+:::
+
+## Why This Is Tightly Coupled with ADL
+
+Hidden friends are unusable without ADL. As noted earlier, an in-class friend definition is not visible at namespace scope, so ordinary lookup cannot find it. Only ADL can: when calling `x == y`, the compiler uses the argument `x` (type `Box<int>`) to pull `Box<int>`'s hidden friend `operator==` into the candidate set.
+
+So hidden friends are ADL's best partner. ADL makes "operators defined inside a class" findable, and hidden friends make "calls that should not be found" unfoundable. Together, the scope of an operator is controlled precisely to "only effective for this type." This is also why the previous piece spent so much effort on ADL; it is the prerequisite for understanding this one.
+
+## A Practical Pattern: Giving a Type Its Comparison Operators
+
+In practice, the recommended template for giving a type its operators looks like this.
+
+```cpp
+class Temperature {
+    double kelvin_;
+public:
+    constexpr explicit Temperature(double k) : kelvin_(k) {}
+    constexpr double k() const { return kelvin_; }
+
+    // hidden friends: all operators written as in-class friends
+    friend constexpr bool operator==(Temperature a, Temperature b) {
+        return a.kelvin_ == b.kelvin_;
+    }
+    friend constexpr bool operator!=(Temperature a, Temperature b) {
+        return !(a == b);   // reuse ==
+    }
+    friend constexpr bool operator<(Temperature a, Temperature b) {
+        return a.kelvin_ < b.kelvin_;
+    }
+    // ... other comparison operators
+};
+```
+
+After C++20 there is an even more economical option: define an `operator<=>` (the three-way comparison operator, covered in another piece in this volume), and the compiler auto-generates `==`, `!=`, `<`, `<=`, `>`, `>=` for you. But if you do not use spaceship, or you want custom semantics for some operator, hidden friends remain the preferred style. Operators in the standard library's iterators and in `std::chrono` duration types are mostly hidden friends.
+
+Next we move into alias templates and using declarations. How `template <typename T> using vec = std::vector<T>;` gives types short names, why alias templates cannot be specialized, and how `using` introduces base-class names in template inheritance, all get covered.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md
new file mode 100644
index 000000000..902649eee
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md
@@ -0,0 +1,177 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: C++11 alias templates (template<typename T> using X = ...) fix the old
+  problem that typedef cannot be parameterized. The _t alias (from C++14) and the
+  _v variable (from C++17) make type_traits clean to write, and using introduces dependent-base
+  names in template inheritance. This piece covers all three uses.
+difficulty: intermediate
+order: 8
+platform: host
+prerequisites:
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+reading_time_minutes: 7
+related:
+- 'Template Friends and Barton-Nackman: The Hidden Friends Trick'
+- 'CRTP: Static Polymorphism with the Curiously Recurring Template Pattern'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 类型别名
+- 泛型
+title: 'Alias Templates and using Declarations: Short Names for Types'
+---
+# Alias Templates and using Declarations: Short Names for Types
+
+C++11 upgraded type aliasing with a new use of `using` and the **alias template**. The old `typedef` can give one type a new name, but it cannot be parameterized. You want a short name for `std::vector<T>`, and `typedef` cannot do it; you have to go through a nested type inside a class template. `using` plus alias templates fix this directly. This piece covers three uses: the alias template itself, the `_t` alias (from C++14) and the `_v` variable (from C++17) used to type_traits, and the role of `using` in introducing base-class names in template inheritance (a follow-up to the `this->` discussion in piece three).
+
+## The Limit of typedef: No Parameterization
+
+`typedef` is an old C tradition, giving a type a new name.
+
+```cpp
+typedef std::vector<int> IntVec;   // IntVec is std::vector<int>
+IntVec v;
+```
+
+That works. But if you want a general alias for "a `vector` of any `T`," `typedef` is stuck. It cannot take template parameters. The pre-C++11 workaround borrows a nested `using` inside a class template.
+
+```cpp
+template <typename T>
+struct VecHelper {
+    using type = std::vector<T>;   // nested inside a class template, so it can be parameterized
+};
+
+VecHelper<int>::type v;   // again with ::type, noisy
+```
+
+This runs, but every use spells `VecHelper<int>::type`, and as noted in the piece on dependent names, you also need `typename`, turning it into `typename VecHelper<T>::type`. Long and awkward.
+
+## C++11 Alias Templates: Parameterizing using
+
+The C++11 alias template cleans this up. The syntax is `template <...> using name = ...`, giving a parameterized type a direct alias.
+
+```cpp
+template <typename T>
+using Vec = std::vector<T>;   // alias template
+
+Vec<int> v = {1, 2, 3};        // equivalent to std::vector<int>
+```
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 alias.cpp -o alias && ./alias
+size = 3
+```
+
+`Vec<int>` is `std::vector<int>`, with no difference in use. Note that an alias template is not a new type. It is purely an "alias." `Vec<int>` and `std::vector<int>` are the same type, fully interchangeable for assignment, comparison, and overloading. This matches `typedef` semantics, with parameterization added.
+
+The payoff of alias templates is more than brevity. They can also express some complex types that `typedef` struggles with, like function pointer types or containers with allocators, where `using` reads far more clearly than `typedef`.
+
+```cpp
+// typedef for function pointer types: the ordering makes your head hurt
+typedef int (*Callback)(int, int);
+
+// using: left-to-right, consistent, far more readable
+using Callback = int(*)(int, int);
+```
+
+Modern C++ basically replaces `typedef` with `using` everywhere, even without parameters, for a consistent style.
+
+## C++14 `_t` and C++17 `_v`: The type_traits Shortcut
+
+The most practical application of alias templates is the `_t` suffix that C++14 added to `<type_traits>`. C++11 type_traits results are nested `::type` or `::value` inside a class, noisy to use.
+
+```cpp
+// C++11: to get the type with reference removed, you need typename + ::type
+typename std::remove_reference<T>::type
+```
+
+C++14 added a `_t` alias template for every type-returning trait, one line.
+
+```cpp
+// C++14: alias template, clean
+std::remove_reference_t<T>
+```
+
+The two are fully equivalent. The `_t` version is just an alias template, defined roughly as `template <typename T> using remove_reference_t = typename remove_reference<T>::type;`. Traits that return a boolean get a `_v` suffix, so `std::is_integral<T>::value` shortens to `std::is_integral_v<T>`. Three things need separating here: the `_t` alias template and the `_v` variable template are both **standard-library helpers** (`_t` from C++14 onward, `_v` from C++17 onward); `::value` itself is a static member constant of `std::integral_constant`, present since C++11, and is a separate thing from variable templates.
+
+A quick check shows the two spellings are equivalent.
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 alias.cpp -o alias && ./alias
+remove_reference_t<int&> is int?  true
+remove_reference<int&>::type is int? true
+```
+
+`_t` lifts the readability of template metaprogramming by a notch. In part three, when we cover concepts and metaprogramming, you will see that `::type` has basically vanished from modern code, replaced entirely by `_t`. This is also why the type_traits examples in earlier pieces of this volume use `_v` suffixes directly (`is_pointer_v`, `is_same_v`). They are the variable-template shortcuts (C++17 onward), the same idea as the `_t` alias templates.
+
+## Alias Templates Cannot Be Specialized
+
+There is a limit alias templates cannot get past: **they cannot be specialized**, neither fully nor partially. If you want a special alias implementation for one concrete type, an alias template cannot do it.
+
+```cpp
+template <typename T>
+using V = T;
+
+// trying to specialize an alias template -- compile error
+template <>
+using V<int> = long;   // error: alias templates cannot be specialized
+```
+
+```text
+alias_bad.cpp:6:1: error: expected unqualified-id before 'using'
+```
+
+GCC's wording is a little abstract, but the meaning is "alias templates do not accept specialization." If you genuinely need "different type aliases for different types," you wrap it in a class template (class templates can be specialized), hiding the alias in a nested `using` and writing specializations of the wrapper. This is a capability gap of alias templates compared with class templates. By design, alias templates are positioned as "pure forwarding," not for type-computation dispatch.
+
+## using in Template Inheritance: Introducing dependent-base Names
+
+Piece three, on dependent bases, said that accessing members of a base class template requires `this->`, because the compiler does not look inside a dependent base at phase one. `using` offers another spelling: **use a `using` declaration to bring the base-class name into the derived-class scope**, and then calls no longer need `this->` each time.
+
+```cpp
+#include <iostream>
+
+template <typename T>
+struct Base {
+    static T kDefault;
+    void greet() { std::cout << "Base::greet\n"; }
+};
+template <typename T>
+T Base<T>::kDefault{42};
+
+template <typename T>
+struct Derived : Base<T> {
+    // using brings Base<T>::kDefault and Base<T>::greet into the Derived scope
+    using Base<T>::kDefault;
+    using Base<T>::greet;
+
+    T fetch() const { return kDefault; }   // direct use, no this->
+    void hello() { greet(); }              // direct use, no this->
+};
+```
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 using_base.cpp -o using_base && ./using_base
+fetch = 42
+Base::greet
+```
+
+`using Base<T>::kDefault` tells the compiler "the name `kDefault` refers to the one in `Base<T>`," binding the lookup so that a later bare `kDefault` in `fetch` finds it without `this->`.
+
+`using` injection and `this->` are two spellings for the same problem, and the choice depends on the situation. If you only occasionally touch one or two base-class members, `this->` written on the spot is lighter. If you frequently touch many base-class members (say, the derived class uses the base's type aliases and functions everywhere), a batch of `using` declarations at the top of the class makes the code cleaner. Both are legitimate modern spellings. `using` has a bonus: it can "inherit" base-class type aliases (`value_type`, `iterator`) so the derived class exposes a unified type interface, something STL container adaptors and derived classes do heavily.
+
+## Alias Templates and Template Argument Deduction
+
+A final note on a post-C++14 development. Alias templates can participate in template argument deduction, which makes code more flexible. For example, if a function takes `std::vector<T>` and you pass a `Vec<int>` (an alias), deduction still works, because the alias is the original type. C++20 CTAD (class template argument deduction) also interacts with alias templates, allowing deduction of alias-template parameters from constructors. That is deeper territory, covered in part three when we discuss concepts and deduction. For this piece, just remember: an alias template is "transparent," fully identical to the original type it points to for deduction, overloading, and type equivalence.
+
+Next is the centerpiece of the concept portion of this volume: CRTP, the curiously recurring template pattern. With the curious structure of "a derived class passes itself as a template argument to its base," it achieves compile-time static polymorphism and avoids the runtime cost of virtual functions. It is a core technique in high-performance libraries like Eigen and expression templates.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
new file mode 100644
index 000000000..2551147d8
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
@@ -0,0 +1,222 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+- 23
+description: CRTP has a derived class pass itself as a template argument to its base,
+  achieving compile-time static polymorphism that avoids the vtable and runtime dispatch
+  of virtual functions. This piece covers its structure, the assembly proof of zero
+  overhead, typical uses like mixins, its pitfalls, and the C++23 deducing-this alternative.
+difficulty: intermediate
+order: 9
+platform: host
+prerequisites:
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+- 'Name Lookup and ADL: How Two-Phase Lookup Works'
+- 'Alias Templates and using Declarations: Short Names for Types'
+reading_time_minutes: 9
+related:
+- 'Project: fixed_vector<T, N>'
+- 'Template Friends and Barton-Nackman: The Hidden Friends Trick'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- CRTP
+- 泛型
+- 零开销抽象
+title: 'CRTP: Static Polymorphism with the Curiously Recurring Template Pattern'
+---
+# CRTP: Static Polymorphism with the Curiously Recurring Template Pattern
+
+CRTP, the Curiously Recurring Template Pattern. Its structure looks odd at first: a derived class passes itself as a template argument to its base. `struct Derived : Base<Derived>`. This "self-reference" trick achieves compile-time **static polymorphism**. When you do not need to decide the concrete type at runtime, it fully avoids the vtable and dispatch cost of virtual functions. Expression templates in Eigen, and the mixin mechanisms in many high-performance libraries, are built on CRTP. This piece covers its structure, the assembly proof of zero overhead, several typical uses, and the pitfalls you cannot avoid.
+
+## What CRTP Looks Like: A Derived Class Passes Itself to Its Base
+
+Start with a minimal example. The base class `Shape` is a template, and its template parameter is "the derived class itself."
+
+```cpp
+#include <iostream>
+
+template <typename Derived>
+struct Shape {
+    const char* name() {
+        return static_cast<Derived*>(this)->name_impl();   // cast this to the derived pointer
+    }
+    double area() {
+        return static_cast<Derived*>(this)->area_impl();
+    }
+};
+
+struct Circle : Shape<Circle> {        // Circle passes itself, Circle, to Shape
+    double r;
+    explicit Circle(double r_) : r(r_) {}
+    const char* name_impl() { return "Circle"; }
+    double area_impl() { return 3.14159 * r * r; }
+};
+
+struct Square : Shape<Square> {
+    double side;
+    explicit Square(double s) : side(s) {}
+    const char* name_impl() { return "Square"; }
+    double area_impl() { return side * side; }
+};
+```
+
+The key line is `struct Circle : Shape<Circle>`. `Circle` inherits `Shape`, but passes `Circle` itself as the template argument. So in the base `Shape<Derived>`, `Derived` is `Circle`, and the base's `area()` calls `static_cast<Derived*>(this)->area_impl()`, which actually calls `Circle::area_impl`.
+
+Run it.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 crtp_basic.cpp -o crtp_basic && ./crtp_basic
+Circle area = 12.5664
+Square area = 9
+```
+
+`Circle` goes through `Circle::area_impl`, `Square` through `Square::area_impl`, each computing its own. The effect looks the same as virtual-function polymorphism, but the mechanism is entirely different.
+
+## Static Polymorphism: The Concrete Type Is Known at Compile Time
+
+Virtual-function polymorphism is **runtime**. At `base->area()`, the concrete type `base` points to is only known at runtime, so the compiler can only generate "look up the vtable, indirect call" code.
+
+CRTP polymorphism is **compile-time**. When `Shape<Circle>::area()` is instantiated, `Derived` is already pinned as `Circle`. `static_cast<Derived*>(this)->area_impl()` is `static_cast<Circle*>(this)->area_impl()`, and the compiler knows clearly it is calling `Circle::area_impl`, so it can call directly or even inline. No vtable, no runtime dispatch.
+
+This is the core value of CRTP: **when the concrete type is known at compile time, replace virtual functions with static polymorphism for zero overhead.**
+
+## The Assembly Proof of Zero Overhead
+
+Talk is cheap, look at the assembly. Write a CRTP version and a virtual-function version, both with the same behavior (return 42), compile with `-O2`, and compare the disassembly of the `use` function.
+
+```cpp
+// crtp_asm.cpp -- CRTP version
+template <typename D>
+struct Base {
+    int compute() { return static_cast<D*>(this)->compute_impl(); }
+};
+struct Concrete : Base<Concrete> {
+    int compute_impl() { return 42; }
+};
+int use_crtp() { Concrete c; return c.compute(); }
+```
+
+The complete disassembly of the CRTP `use_crtp` is just two instructions.
+
+```text
+0000000000000000 <_Z8use_crtpv>:
+   0:   b8 2a 00 00 00   mov    $0x2a,%eax    ; 0x2a = 42, put the result straight into the return value
+   5:   c3               ret
+```
+
+`compute()` and `compute_impl()` are both inlined, and the compiler computes the result, 42, directly, skipping even the function call. `use_crtp` is simply "put 42 into eax, return."
+
+Now the virtual-function version (called through a reference to force virtual dispatch).
+
+```cpp
+// vtable_asm.cpp -- virtual function version
+struct Base {
+    virtual int compute() = 0;
+    virtual ~Base() = default;
+};
+struct Concrete : Base {
+    int compute() override { return 42; }
+};
+int use_virtual(Base& b) { return b.compute(); }   // through a reference, the compiler cannot devirtualize
+```
+
+The disassembly of `use_virtual` is much longer.
+
+```text
+0000000000000000 <_Z11use_virtualR4Base>:
+   0:   48 8b 07         mov    (%rdi),%rax        ; load the vtable pointer from the object
+   3:   48 8d 15 ...     lea    ...(%rip),%rdx     ; the vtable address of Concrete
+   a:   48 8b 00         mov    (%rax),%rax        ; load the function pointer of compute from the vtable
+   d:   48 39 d0         cmp    %rdx,%rax          ; speculative devirtualization: is it Concrete?
+  10:   75 0e            jne    20                 ; only indirect-call if not
+  12:   b8 2a 00 00 00   mov    $0x2a,%eax         ; it is Concrete, return 42 directly
+  17:   c3               ret
+```
+
+The virtual version has two dereferences of the vtable pointer (`mov (%rdi)` to get the vtable, `mov (%rax)` to get the function pointer), plus a comparison and a conditional jump (GCC's "speculative devirtualization": first guess whether `b` is `Concrete`; if the guess hits, return directly; if it misses, do the real indirect call). Even at `-O2`, this vtable access and devirtualization check still cost something.
+
+The contrast is plain. The CRTP version is two instructions with zero memory access. The virtual version is seven instructions with two memory accesses (the vtable). This is the most direct evidence of "zero-overhead static polymorphism." In a numerical library like Eigen, expression evaluation is flattened entirely into compile time via CRTP, and at runtime it is just a sequence of direct arithmetic instructions with no polymorphic dispatch. That is the root reason it can be as fast as a hand-written loop.
+
+## Typical Uses of CRTP
+
+CRTP is not only for static polymorphism. It has several common uses.
+
+**Static polymorphism** (the focus of this piece). The base defines the interface skeleton, the derived class provides the concrete implementation, bound at compile time with no virtual-function cost. It fits "fixed interface, varied implementations, performance-sensitive" scenarios, like operations in numerical libraries or container iterators.
+
+**Mixin.** The base injects a piece of generic functionality into the derived class, which only needs to provide the underlying data. For example, auto-generate a full set of comparison operators for any type that supports `<`.
+
+```cpp
+template <typename Derived>
+struct Comparable {
+    friend bool operator>(const Derived& a, const Derived& b)  { return b < a; }
+    friend bool operator<=(const Derived& a, const Derived& b) { return !(b < a); }
+    friend bool operator>=(const Derived& a, const Derived& b) { return !(a < b); }
+    friend bool operator!=(const Derived& a, const Derived& b) { return !(a == b); }
+};
+
+struct Point : Comparable<Point> {
+    int x, y;
+    Point(int x_, int y_) : x(x_), y(y_) {}
+    friend bool operator<(const Point& a, const Point& b) { return a.x < b.x; }
+    friend bool operator==(const Point& a, const Point& b) { return a.x == b.x; }
+};
+// Point now has > <= >= != automatically, only < and == had to be implemented
+```
+
+Run it to confirm the mixin-injected operators actually work.
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 comparable.cpp -o comparable && ./comparable
+p1 < p2:  true
+p1 > p2:  false
+p1 <= p2: true
+p1 >= p2: false
+p1 != p2: true
+```
+
+`Point` only implements `<` and `==`; the other four comparison operators are all auto-filled by `Comparable<Point>`.
+
+As long as `Point` implements `<` and `==`, mixing in `Comparable<Point>` fills in all the other comparison operators automatically. This pairs with the Barton-Nackman trick from the previous piece: CRTP provides the structure, friend injection provides the operators.
+
+**Compile-time interface injection / policy injection.** The base can require the derived class to provide certain typedefs or constants, checked at compile time, implementing a "static interface." For example, the base can write `using value_type = typename Derived::value_type;`, and if the derived class does not expose `value_type`, it fails to compile. This kind of "concept-like" compile-time constraint was commonly faked with CRTP before concepts existed.
+
+**Expression templates.** In Eigen, `a + b * c` does not produce temporary matrices. Instead it produces an "expression type" that records the operation, and evaluates it all at once on assignment, avoiding intermediate temporaries. This mechanism is built entirely on CRTP and is its most stunning application. Part three of this volume takes it apart.
+
+## Pitfalls of CRTP
+
+CRTP is powerful, but it has pitfalls to avoid.
+
+**The derived class is incomplete during base construction.** When the base constructor runs, the derived part has not been constructed yet. Calling `static_cast<Derived*>(this)` inside the base constructor to access derived members is undefined behavior (the object is not fully formed). The same goes for the base destructor. CRTP's cross-layer calls are only safe when the object is complete at the moment of the call, not during construction or destruction.
+
+**The safety assumption of `static_cast`.** `static_cast<Derived*>(this)` assumes `this` actually points to a `Derived` object. You guarantee this when you write `struct Derived : Base<Derived>`. The good news is the type system actually catches part of this for you: if someone writes `struct Wrong : Base<Other>` (where `Wrong` and `Other` are unrelated), the `static_cast<Other*>(this)` inside the base usually fails to compile, because `Wrong*` and `Other*` are unrelated types and `static_cast` refuses the conversion. So CRTP is more type-safe than it looks, as long as you honestly pass the derived class itself to the base.
+
+**CRTP does not interoperate with virtual functions.** CRTP's `area()` is not virtual, so you cannot stuff `Circle*` and `Square*` into the same `Shape*` array and call `area()` uniformly. Scenarios that need a runtime heterogeneous collection still require virtual functions. CRTP fits "the concrete type is known at compile time," and that is its boundary.
+
+## C++23 deducing this: A Modern Replacement for CRTP
+
+CRTP is a little convoluted to write (`static_cast<Derived*>(this)`). C++23 offers a more direct replacement called **deducing this** (explicit object parameter). It lets a member function receive a `this` parameter explicitly, and the compiler deduces it from the type of the calling object.
+
+```cpp
+// C++23 deducing this style: Shape is no longer a template
+struct Shape {
+    // the type of self is deduced from the calling object, no longer a hardcoded Derived
+    double area(this auto const& self) { return self.area_impl(); }
+};
+
+struct Circle : Shape {   // Circle still inherits Shape, but no longer needs to pass Shape<Circle> as a template argument
+    double r;
+    double area_impl() const { return 3.14159 * r * r; }
+};
+// Circle c; c.area() deduces self as Circle const&, calling Circle::area_impl
+```
+
+deducing this makes static polymorphism read more like ordinary functions, without `static_cast` and without the derived class passing itself to itself. It is a major C++23 feature, covered in detail in part three of this volume (metaprogramming) and in vol2 on modern features. Until then, CRTP remains the standard way to do static polymorphism in C++17 and earlier projects, and you will see it everywhere in Eigen and Boost code.
+
+The next piece closes the concept portion of this volume: a `fixed_vector<T, N>` project. With a compile-time fixed-size contiguous store, it strings together everything from this volume, templates, non-type parameters, iterators, and CRTP (optional), into a fixed-length container with zero dynamic allocation, and compares it with the C++23/26 `std::inplace_vector`.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md
new file mode 100644
index 000000000..801f77e6f
--- /dev/null
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md
@@ -0,0 +1,188 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+- 26
+description: String together everything from the first 9 pieces and implement a compile-time
+  fixed-capacity, contiguous, zero-allocation vector. Full code with tests, then compare
+  it against C++26 std::inplace_vector and EASTL/Boost/Folly counterparts.
+difficulty: intermediate
+order: 10
+platform: host
+prerequisites:
+- 'CRTP: Static Polymorphism with the Curiously Recurring Template Pattern'
+- 'Non-Type Template Parameters: From Integers to C++20 Floats and Class Types'
+- 'Class Templates: Members, Dependent Names, and Lazy Instantiation'
+reading_time_minutes: 8
+related:
+- 'Templates, From Scratch: A Code Recipe with Placeholders'
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 容器
+- vector
+- 零开销抽象
+title: 'Project: fixed_vector<T, N>'
+---
+# Project: fixed_vector&lt;T, N&gt;
+
+We have reached the point where the concepts from the first 9 pieces should work together. Let us implement a `fixed_vector<T, N>`: a compile-time fixed-capacity, contiguous, **zero-allocation** vector. It pulls together class templates, non-type template parameters, and iterators, and if you like, CRTP for an iterator interface. This is not a thought experiment. The standard library's `std::inplace_vector` (C++26) is its "official" version, and industry had EASTL's `fixed_vector`, Boost's `static_vector`, and Folly's `small_vector` using the same idea long before. We will write a teaching-simplified version, explain each design choice, and compare it against the standard library at the end.
+
+## Goal: What Kind of Container
+
+First, nail down what `fixed_vector` must satisfy.
+
+One, the capacity `N` is fixed at compile time, as a non-type template parameter. Two, elements are stored contiguously, accessible with `operator[]` for random access, with raw pointers serving as iterators. Three, **no heap allocation**, all elements live in the object's own storage, which is especially useful in embedded, real-time, or no-exception-allowed environments. Four, the element count can change dynamically (from 0 to N), which differs from `std::array` that constructs all elements at compile time. `fixed_vector` constructs on demand.
+
+These goals match `std::inplace_vector` exactly. cppreference defines `inplace_vector` as "a dynamically-resizable array with contiguous inplace storage," with a compile-time-fixed capacity of N and elements stored inside the object itself. Our `fixed_vector` is a teaching-scale version of it.
+
+## Skeleton
+
+The template signature is `template <typename T, std::size_t N>`, one type parameter plus one non-type parameter. Storage uses `std::array<T, N>` as the backing, sparing us alignment and raw memory management, with a `size_` tracking the current element count.
+
+```cpp
+#include <array>
+#include <cstddef>
+#include <stdexcept>
+
+template <typename T, std::size_t N>
+class FixedVector {
+    std::array<T, N> data_{};   // fixed storage, on the stack, no heap allocation
+    std::size_t size_ = 0;
+public:
+    static constexpr std::size_t capacity_v = N;
+    // ... member functions
+};
+```
+
+`data_` is a `std::array<T, N>`, itself contiguous storage. `size_` tracks how many elements are actually in use. `capacity_v` is a static constant exposing the capacity, a typical use of the non-type parameter `N`.
+
+## push_back and Boundary Handling
+
+`push_back` appends an element at the end. The key boundary is capacity exhaustion: what happens beyond `N`. The standard library's `inplace_vector` throws `std::bad_alloc` in that case (note `bad_alloc`, not `out_of_range`, per the `inplace_vector` spec). Our teaching version throws `std::out_of_range` for clarity.
+
+```cpp
+constexpr void push_back(const T& value) {
+    if (size_ >= N) {
+        throw std::out_of_range("FixedVector full");
+    }
+    data_[size_++] = value;
+}
+```
+
+Note the whole function is `constexpr`. In C++20 this means `push_back` can execute at compile time (as long as `T`'s operations are constant expressions). All members of `fixed_vector` can be made `constexpr`, the same property that makes `std::array` a good fit for compile-time computation.
+
+## Element Access and Iterators
+
+`operator[]` forwards straight to the underlying `std::array`, with no bounds check (matching `std::vector::operator[]`; use `at()` for checked access).
+
+```cpp
+constexpr T& operator[](std::size_t i) { return data_[i]; }
+constexpr const T& operator[](std::size_t i) const { return data_[i]; }
+constexpr std::size_t size() const { return size_; }
+```
+
+Iterators are the most elegant part of this implementation. Because elements are contiguous, a raw pointer `T*` is inherently a type that satisfies the random-access iterator requirements (supports `*`, `++`, `+n`, comparison). So `begin()` and `end()` just return pointers, with no custom iterator class.
+
+```cpp
+constexpr T* begin() { return data_.data(); }
+constexpr T* end() { return data_.data() + size_; }
+constexpr const T* begin() const { return data_.data(); }
+constexpr const T* end() const { return data_.data() + size_; }
+```
+
+`data_.data()` returns a pointer to the first element of the backing array, and `end()` points one past the current last element. With this pair of `begin/end`, range-for loops, `std::sort`, `std::find`, and other standard algorithms all work directly on `fixed_vector`, because they only need the iterator interface, and a raw pointer satisfies it. This is the STL's "iterators unify containers and algorithms" philosophy in action.
+
+## Full Code and Tests
+
+Stitch the above together and add a `main` to run it.
+
+```cpp
+#include <array>
+#include <cstddef>
+#include <iostream>
+#include <stdexcept>
+
+template <typename T, std::size_t N>
+class FixedVector {
+    std::array<T, N> data_{};
+    std::size_t size_ = 0;
+public:
+    static constexpr std::size_t capacity_v = N;
+
+    constexpr void push_back(const T& value) {
+        if (size_ >= N) throw std::out_of_range("FixedVector full");
+        data_[size_++] = value;
+    }
+    constexpr T& operator[](std::size_t i) { return data_[i]; }
+    constexpr const T& operator[](std::size_t i) const { return data_[i]; }
+    constexpr std::size_t size() const { return size_; }
+
+    constexpr T* begin() { return data_.data(); }
+    constexpr T* end() { return data_.data() + size_; }
+    constexpr const T* begin() const { return data_.data(); }
+    constexpr const T* end() const { return data_.data() + size_; }
+};
+
+int main() {
+    FixedVector<int, 8> v;
+    for (int i = 1; i <= 5; ++i) v.push_back(i * 10);
+
+    std::cout << "size = " << v.size() << " capacity = " << decltype(v)::capacity_v << "\n";
+    std::cout << "elements: ";
+    for (auto x : v) std::cout << x << " ";
+    std::cout << "\n";
+    std::cout << "v[2] = " << v[2] << "\n";
+    std::cout << "sizeof(FixedVector<int,8>) = " << sizeof(FixedVector<int, 8>) << "\n";
+    std::cout << "sizeof(int*) = " << sizeof(int*) << " (contrast: a dynamic vector holds at least 3 pointers)\n";
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 fixed_vector.cpp -o fixed_vector && ./fixed_vector
+size = 5 capacity = 8
+elements: 10 20 30 40 50
+v[2] = 30
+sizeof(FixedVector<int,8>) = 40
+sizeof(int*) = 8 (contrast: a dynamic vector holds at least 3 pointers)
+```
+
+Check a few key results. `size = 5 capacity = 8`: 5 elements pushed, capacity 8. The range-for loop prints `10 20 30 40 50`, confirming the raw-pointer iterators work. `v[2] = 30`, `operator[]` random access is fine. The most telling line is `sizeof(FixedVector<int,8>) = 40`: 8 `int`s take 32 bytes, plus 8 bytes for `size_`, exactly 40, with **no heap pointer** inside. By contrast, `std::vector` holds at least three pointers (data, capacity, size) plus a heap allocation.
+
+## Why Zero Allocation Matters
+
+No heap pointer in `sizeof` means all of `fixed_vector`'s storage lives inside the object itself. That has practical benefits.
+
+Predictable performance. No heap allocation means no allocator overhead or memory fragmentation, and construction and destruction are deterministic. On hot paths in real-time systems or game engines, a single `std::vector` heap allocation can be a few microseconds of jitter; `fixed_vector` has none.
+
+Clearer exception-safety bounds. `fixed_vector` only throws on capacity exhaustion (`push_back` past N), unlike `std::vector` which can throw `bad_alloc` on reallocation. In environments that disable exceptions or the heap (many embedded projects), `fixed_vector` works where `std::vector` does not.
+
+Cache friendliness. Elements are contiguous and inside the object, an access pattern that is very friendly to the CPU cache, like `std::array` and `std::vector`.
+
+## Comparison with std::inplace_vector (C++26)
+
+`std::inplace_vector` is the standard-library version of this idea. Its feature-test macro `__cpp_lib_inplace_vector` (current value `202603L`) corresponds to **C++26** (early proposals targeted C++23, but it landed in C++26). Its design closely matches our `fixed_vector`: compile-time-fixed capacity, contiguous storage, no heap allocation, elements constructed on demand.
+
+The standard version is far more complete than our teaching one. It has a full set of member functions: `emplace_back`, `try_push_back` (when full, does not throw and returns an empty `std::optional<reference>`), `unchecked_push_back` (no check, caller guarantees room, for hot paths), `insert`, `erase`, `resize`, and more. The exhaustion policy is also more nuanced: `push_back` throws `std::bad_alloc` when full, `try_push_back` returns an empty optional when full, and `unchecked_push_back` assumes room and just appends. This "throw / try / unchecked" three-tier API is a mature pattern for industrial container design.
+
+Industry had counterparts before this. EASTL (EA's STL replacement) has `fixed_vector`, Boost.Container has `static_vector`, and Folly (Facebook) has `small_vector` (with small-buffer optimization). Each has its own emphasis, but the core is the same: contiguous storage plus a compile-time or semi-compile-time capacity, avoiding heap allocation. Our `FixedVector` extracts the core skeleton to explain it; once you understand it, reading these industrial implementations becomes easy.
+
+## Directions to Extend
+
+This teaching version is missing a few pieces, good directions for practice.
+
+Add `try_push_back` and `unchecked_push_back`, matching the `inplace_vector` three-tier API. `try_push_back` returns `std::optional<reference>`, an empty optional when full; `unchecked_push_back` assumes room, skipping the check.
+
+Use aligned raw memory instead of `std::array` to construct on demand. Right now `std::array<T, N>` default-constructs all N elements even if you use only 3; a real `inplace_vector` uses an `alignas(T)` raw byte array and placement-new only on `push_back`, skipping useless construction. This involves `std::optional`, placement new, and manual destruction, closer to the standard library implementation.
+
+Add a CRTP interface to the iterator. If you want `fixed_vector`'s iterator to support custom behavior (say, bounds checking in debug mode), you can write an iterator base with CRTP. This ties piece 9's CRTP to the iterator here.
+
+---
+
+With that, part one of this volume, "Template Basics (C++11-14)," is complete. Starting from a code recipe, through the compilation model of function templates, lazy instantiation of class templates, the pattern matching of specialization and partial specialization, non-type parameters, two-phase name lookup and ADL, hidden friends and Barton-Nackman, alias templates, and CRTP static polymorphism, finally welding them all together with `fixed_vector`. Part two (Modern Template Techniques, C++17) continues with type traits, SFINAE, `if constexpr`, variadic templates, fold expressions, and perfect forwarding, completing the metaprogramming toolbox. Part three (C++20-23) adds concepts, requires, and reflection, turning TMP from dark arts into code a person can write. On the templates road, we have only just set out.
diff --git a/documents/en/vol4-advanced/vol1-basics-cpp11-14/index.md b/documents/en/vol4-advanced/vol1-basics-cpp11-14/index.md
index f1d6cd20c..f403eb001 100644
--- a/documents/en/vol4-advanced/vol1-basics-cpp11-14/index.md
+++ b/documents/en/vol4-advanced/vol1-basics-cpp11-14/index.md
@@ -1,29 +1,25 @@
 ---
-title: Template Basics (C++11-14)
-description: 'The core fundamentals of C++ template programming: a complete introduction
-  from function templates to CRTP (Curiously Recurring Template Pattern)'
-translation:
-  source: documents/vol4-advanced/vol1-basics-cpp11-14/index.md
-  source_hash: e96e81bf6d198dd9b6e5868cff08185a46428eb033e6250dc3bb8f431a3591ca
-  translated_at: '2026-05-26T11:39:12.935881+00:00'
-  engine: anthropic
-  token_count: 89
+title: "Template Basics (C++11-14)"
+description: "The core foundation of C++ template programming: a complete introduction from function templates to CRTP."
 ---
+
 # Template Basics (C++11-14)
 
-> Status: To be written
+C++ templates are the core mechanism of generic programming. This part moves from "using templates" to "writing libraries, reading STL source," covering the compilation model, specialization and partial specialization, non-type parameters, two-phase name lookup, hidden friends, alias templates, and CRTP, finally welding the first nine pieces together with a `fixed_vector<T, N>` project.
 
-C++ templates are the core mechanism of generic programming. This section builds a complete foundational knowledge system of templates from scratch, covering function templates, class templates, specialization and partial specialization, non-type parameters, name lookup, friend injection, aliases, inheritance, and CRTP.
+Every piece ships with "run it and see" real compile output, traps written up as `::: warning` blocks, and key compile-time behavior backed by assembly.
 
-## Chapter Contents (To be written)
+Runnable examples live in [code/examples/vol4/vol1-basics-cpp11-14/](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/tree/main/code/examples/vol4/vol1-basics-cpp11-14): the four most reusable ones (fixed_vector, CRTP static polymorphism, the Comparable mixin, and type_traits from scratch), each compiles with `g++ -std=c++20 xxx.cpp`.
 
-1. Template Introduction
-2. Function Templates
-3. Class Templates
-4. Template Specialization and Partial Specialization
-5. Non-Type Template Parameters
-6. Template Parameter Dependence and Name Lookup
-7. Template Friends and Barton-Nackman
-8. Template Aliases and Using Declarations
-9. Templates and Inheritance (CRTP)
-10. Comprehensive Project: fixed_vector&lt;T, N&gt;
+<ChapterNav variant="sub">
+  <ChapterLink href="01-templates-introduction">Templates, From Scratch: A Code Recipe with Placeholders</ChapterLink>
+  <ChapterLink href="02-function-templates-deep">Function Templates, In Depth: Compilation Model and the No-Partial-Specialization Trap</ChapterLink>
+  <ChapterLink href="03-class-templates">Class Templates: Members, Dependent Names, and Lazy Instantiation</ChapterLink>
+  <ChapterLink href="04-specialization-partial">Template Specialization and Partial Specialization: The Art of Pattern Matching</ChapterLink>
+  <ChapterLink href="05-non-type-parameters">Non-Type Template Parameters: From Integers to C++20 Floats and Class Types</ChapterLink>
+  <ChapterLink href="06-name-lookup-and-adl">Name Lookup and ADL: How Two-Phase Lookup Works</ChapterLink>
+  <ChapterLink href="07-friends-and-barton-nackman">Template Friends and Barton-Nackman: The Hidden Friends Trick</ChapterLink>
+  <ChapterLink href="08-alias-and-using">Alias Templates and using Declarations: Short Names for Types</ChapterLink>
+  <ChapterLink href="09-crtp">CRTP: Static Polymorphism with the Curiously Recurring Template Pattern</ChapterLink>
+  <ChapterLink href="10-fixed-vector">Project: fixed_vector</ChapterLink>
+</ChapterNav>
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md b/documents/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md
new file mode 100644
index 000000000..feab06435
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/01-templates-introduction.md
@@ -0,0 +1,209 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 把模板说回它本来样子:一份带占位符的代码配方。讲清它和宏、和虚函数多态的区别,以及 C++ 里函数、类、变量、别名四种模板实体各管什么
+difficulty: intermediate
+order: 1
+platform: host
+prerequisites:
+- 卷一 · 函数模板
+reading_time_minutes: 11
+related:
+- 函数模板深化:编译模型与 extern template
+- 类模板:成员、依赖名与惰性实例化
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 模板导论:从一份代码配方说起
+---
+# 模板导论:从一份代码配方说起
+
+咱们在卷一已经写过函数模板,知道 `template <typename T> T max_value(T a, T b)` 这么一写,编译器就能照着给 `int`、给 `double`、给 `std::string` 各生成一份代码。这一卷咱们不再停留在「怎么用」,而是想搞明白另外几件事:模板到底是个什么东西,它凭什么能做到「写一遍、套多种类型」,以及这套机制背后的代价是什么。把这些底层细节吃透,后面无论是读 STL 源码、读 Chromium 那种重模板的工业代码,还是自己动手写库,心里都不会发虚。
+
+## 模板到底是什么:一份带占位符的代码配方
+
+笔者喜欢把模板想成一份**代码配方**。模板本身不是代码,而是「代码该怎么写」的说明。`T` 是配方里的占位符,意思是「这里先空着,等真正用到的时候再填」。
+
+```cpp
+template <typename T>
+T max_value(T a, T b) {
+    return (a > b) ? a : b;
+}
+```
+
+上面这几行,编译器不会为它生成任何机器码。它只是把配方记下来。真正让机器码出现的,是**实例化**(instantiation)。当咱们写下 `max_value(3, 5)`,编译器看到 `3` 和 `5` 都是 `int`,于是照着配方抄一份,把 `T` 全部换成 `int`,得到一个真实的 `int max_value(int, int)` 函数,这一份才会被编译成机器码。
+
+```cpp
+int x = max_value(3, 5);        // T=int,编译器抄出一份 int 版本
+double y = max_value(1.0, 2.0); // T=double,再抄一份 double 版本
+```
+
+这两次调用,编译器抄出了两个完全独立的函数,各自编译。效果跟咱们手写两个重载没有区别。
+
+这里有个反直觉的点值得停一下。很多人以为模板是「运行时根据类型选一个版本」,其实它是「编译期为每种用到的类型各生成一份」。所以模板调用**没有运行时开销**:调的就是普通函数,没有虚函数表那一套分派。代价咱们待会说。
+
+::: warning 占位符不是宏替换
+有人把模板理解成「高级一点的宏替换」,这只对了一半。宏(`#define`)是预处理阶段的纯文本替换,不认类型、不认作用域,稍不留神就翻车。模板的替换发生在编译阶段,编译器清楚 `T` 是个类型,会做类型检查、重载解析、名字查找。后面讲两阶段查找的时候咱们会看到,这套机制比宏精细得多。拿「带类型检查的宏」当初步印象可以,但别停在这一步。
+:::
+
+## 为什么不是宏,也不是虚函数
+
+「逻辑相同、类型不同」这个需求,C++ 里有好几条路能走。咱们把最常被拿来比的三条放一起看。
+
+宏这条路,`#define max(a, b) ((a) > (b) ? (a) : (b))` 能用,但它是预处理期的纯文本替换。参数会被求值两次、不认类型、没有作用域、调试器里看不到它的影子。卷一讲函数模板的时候提过,Windows 上 `<windows.h>` 的 `max` 宏能让您血压拉满。宏能干的事,模板几乎都能干得更好。
+
+虚函数多态这条路,把 `max` 写成虚函数,运行时根据对象的实际类型分派到对应实现。它要求所有参与类型处在同一个继承体系里,而且每次调用都要走一次虚函数表查找,有运行时开销。更要命的是,`int`、`double` 这些内置类型根本进不了您的继承体系。
+
+模板这条路,编译期为每种用到的类型各生成一份代码,调用的是普通的、可内联的函数。没有继承体系的约束,内置类型、自定义类型一视同仁;没有运行时分派开销。
+
+这三条路谁也不替代谁。虚函数适合「同一接口、运行时才知道具体实现」的场景,比如插件系统、GUI 事件分发;模板适合「同一份逻辑、编译期就知道类型」的场景,比如容器和算法。至于宏,基本能不用就不用。
+
+## C++ 里有四种模板实体
+
+很多人以为模板就是函数模板和类模板两种,其实 C++ 标准里模板能定义四种实体。cppreference 给的定义是:模板是定义一族(family)实体的 C++ 实体。
+
+函数模板(function template)定义一族函数,`std::max`、`std::sort` 都是。类模板(class template)定义一族类,`std::vector`、`std::map` 都是。这两种从 C++98 就有,是咱们最熟的。除此之外还有两种稍新的:变量模板(variable template,C++14 起)定义一族变量或静态成员;别名模板(alias template,C++11 起)定义一族类型别名。
+
+变量模板解决的是一个很朴素的需求:给「每个类型」配一个常量。在 C++14 之前,大家是用类模板的静态成员模拟的:
+
+```cpp
+// C++14 之前的老写法:用类模板的静态成员模拟「参数化的常量」
+template <typename T>
+struct pi_trait {
+    static constexpr T value = T(3.1415926535897932385L);
+};
+double r = pi_trait<double>::value * 2.0;
+```
+
+C++14 有了变量模板,直接写成一个参数化的变量,清爽多了:
+
+```cpp
+template <typename T>
+constexpr T pi = T(3.1415926535897932385L);  // 变量模板
+
+double r = pi<double> * 2.0;  // 用起来像普通常量,只是带个 <T>
+```
+
+标准库里 `std::numeric_limits<T>::max()` 之所以是函数而不是变量,部分原因就是它诞生的时候变量模板还不存在。`std::tuple_size`、`std::extent` 这些后来都补了对应的 `_v` 变量模板版本(比如 `std::extent_v<T>`,C++17 起),就是为了让大家少写一句 `::value`。cppreference 上变量模板的特性测试宏是 `__cpp_variable_templates = 201304L`,对应 C++14。
+
+别名模板解决的是「给一族类型起个短名字」:
+
+```cpp
+// 没有 alias template 的年代,要给 vector<T> 起别名得借助类模板的嵌套 using
+template <typename T>
+struct vec_alias { using type = std::vector<T>; };
+typename vec_alias<int>::type v;  // 又是 typename 又是 ::type,啰嗦
+
+// C++11 alias template,一行搞定
+template <typename T>
+using vec = std::vector<T>;
+vec<int> v;  // 干净
+```
+
+这一卷后面会专门讲别名模板,这里咱们先有个印象:**C++ 里能被参数化的,不只是函数和类**。
+
+## 三种模板参数
+
+模板的「占位符」有三种,对应三种参数。
+
+类型参数(type parameter),写作 `typename T` 或 `class T`,占位的是一个类型,最常见。非类型参数(non-type parameter),写作 `template <int N>` 这种形式,占位的是一个编译期已经知道的**值**,可以是整数、指针、引用,以及 C++20 起的浮点数和满足一定条件的类类型。模板模板参数(template template parameter),占位本身就是一个模板。
+
+```cpp
+template <typename T, std::size_t N>   // T 是类型参数,N 是非类型参数
+struct array {
+    T data[N];
+};
+
+template <template <typename> class Container>  // Container 是模板模板参数
+struct wrapper {
+    Container<int> c;
+};
+```
+
+`std::array<T, N>` 是前两种配合的经典例子:`T` 是元素类型,`N` 是数组大小,`N` 必须在编译期就知道。模板模板参数平时用得少,但写高阶泛型库(比如「换一个底层容器」的策略)时会碰到。这三种参数本卷后面都会各自展开,其中非类型参数那一篇还会专门讲 C++20 对它的大幅度放宽。
+
+## 模板是编译期图灵完备的
+
+这件事值得单独拎出来说,因为它决定了模板能走多远。**C++ 的模板机制是图灵完备的**,也就是说,只要愿意,咱们可以在编译期用模板做任意复杂的计算,分支、循环(用递归模拟)、任何逻辑全在编译阶段完成,运行时拿到的是已经算好的结果。
+
+一个最小的例子,编译期算阶乘:
+
+```cpp
+template <unsigned N>
+struct Factorial {
+    static constexpr unsigned value = N * Factorial<N - 1>::value;
+};
+
+template <>
+struct Factorial<0> {              // 递归终止:0! = 1
+    static constexpr unsigned value = 1;
+};
+
+template <unsigned N>
+constexpr unsigned factorial_v = Factorial<N>::value;  // C++14 变量模板,顺手用上
+```
+
+跑一下,乘法全部发生在编译期:
+
+```bash
+$ g++ -std=c++14 factorial.cpp -o factorial && ./factorial
+5! = 120
+10! = 3628800
+```
+
+```cpp
+static_assert(Factorial<5>::value == 120, "");      // 编译期就验过
+static_assert(factorial_v<10> == 3628800, "");
+```
+
+`Factorial<5>::value` 在程序跑起来之前就已经是 `120` 了。这就是模板元编程(template metaprogramming, TMP)的根:把计算塞进编译期。它能做出很厉害的东西,表达式模板、编译期字符串、`constexpr` 编译期解析都建立在上面,代价是编译慢、报错难读、代码可读性差。本卷第三部分(C++20/23 元编程)会专门讲 C++ 怎么用 `concepts`、`consteval`、`if constexpr` 把 TMP 从「黑魔法」拉回「人能写的代码」。这一篇咱们只要记住一件事:**模板不只是生成代码,它本身就能在编译期算东西**。
+
+## 代价:实例化、代码膨胀、header-only
+
+模板不是白嫖的,它有三笔代价。
+
+第一笔是**惰性实例化**。类模板的成员函数,只有真正被用到的那几个才会被实例化。写一个 `std::vector<Heavy>` 不会把 `vector` 的所有成员函数都实例化一遍,只实例化您实际调用的那些。这也是为什么 STL 敢把那么多功能塞进一个模板里,没用到就不付钱。
+
+```cpp
+template <typename T>
+struct Demo {
+    void used_function() { T t{}; /* ... */ }
+    void unused_function() {
+        // 这里哪怕写了 T 上根本不存在的成员,也不会报错
+        // 因为这个函数从没被调用,根本不会被实例化
+    }
+};
+
+int main() {
+    Demo<int> d;
+    d.used_function();   // 只实例化这一个
+    // 没调用 unused_function(),所以它不会被实例化,里面的胡写编译器看不见
+}
+```
+
+这条特性有利有弊。利是编译快、二进制小;弊是某些错误要等到真正用了才暴露,藏得深。
+
+第二笔是**代码膨胀**。每种用到的类型各生成一份代码。`max_value` 给 `int`、`double`、`std::string` 各用一次,就是三份函数。对小函数无所谓,对大模板(比如某些 STL 算法的完整特化)累积起来会让二进制明显变大。这一卷讲函数模板深化的那一篇会讲 `extern template`,就是用来控制这种膨胀的。
+
+第三笔是 **header-only**。模板的定义必须在它被实例化的地方可见,所以绝大多数模板库都是纯头文件库,boost 是典型例子。您不能像普通函数那样把声明放头文件、实现放 `.cpp`。这一点直接导致了 C++ 「编译慢」这个老问题:每个翻译单元都要重新解析一遍模板定义。C++20 的模块(modules)就是为了治这个病,但那是另一个大话题。
+
+## export template:一个被放弃的尝试
+
+说到「模板定义必须可见」,其实 C++98 标准里委员会给过一条出路,叫 `export template`。想法很美好:加了 `export` 的模板,使用者只要看到声明就能实例化,不用包含定义,从而实现模板的分离编译。
+
+现实很骨感。整套 C++98 标准里,只有 Edison Design Group(EDG)的前端和基于它的 Comeau 编译器真正实现了 `export template`,GCC、Clang、MSVC 全部没实现。原因是这套机制实现起来极其复杂,收益又看不出多少。到了 C++11,委员会干脆把它从标准里删掉,cppreference 上对它的标注是 `(until C++11)`。
+
+这段历史给咱们的提示是:**模板的分离编译,直到今天仍然是个没被彻底解决的问题**。`extern template` 能减少重复实例化,但不能真正把声明和定义分开;C++20 模块是另一套全新的解法,生态还在建设中。所以现阶段,模板代码基本还是得写在头文件里,这是 C++ 程序员要接受的现实。
+
+## 这卷要走的路
+
+这一篇咱们把模板说回了它本来样子:一份带占位符的代码配方,编译期照配方生成真实代码,零运行时开销,代价是代码膨胀和必须写在头文件里。接下来咱们从「会用」往「写库」推进。下一篇把函数模板的编译模型、`extern template`,还有「函数模板不能偏特化」这个经典坑掰开讲透;之后是类模板、特化与偏特化、非类型参数、两阶段名字查找、友元注入、别名模板,最后用 CRTP 收口静态多态,再用一个 `fixed_vector` 综合项目把前面学的全串起来。
+
+读到这儿,您应该对模板「是什么」有了底气。接下来的篇幅,咱们把它「为什么」一件件讲透。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md b/documents/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md
new file mode 100644
index 000000000..ca334af0e
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/02-function-templates-deep.md
@@ -0,0 +1,266 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 从写库的视角重看函数模板:包含模型为什么逼着模板写进头文件、显式实例化和 extern template 怎么控制代码膨胀,以及那个经典坑——函数模板不能偏特化,得用重载绕
+difficulty: intermediate
+order: 2
+platform: host
+prerequisites:
+- 卷一 · 函数模板
+- 模板导论:从一份代码配方说起
+reading_time_minutes: 12
+related:
+- 类模板:成员、依赖名与惰性实例化
+- 模板特化与偏特化:模式匹配的艺术
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 函数模板深化:编译模型与那个不能偏特化的坑
+---
+# 函数模板深化:编译模型与那个不能偏特化的坑
+
+卷一咱们写过函数模板,知道语法、实例化、推导、特化、重载那一套。这一篇换个视角,从「想拿模板写个库」的角度重新看函数模板,有三件事绕不开:模板的编译模型为什么跟普通函数不一样,显式实例化和 `extern template` 怎么帮您控制代码膨胀,以及一个能让人盯屏幕半天的坑——函数模板不能偏特化。把这三件讲透,您再看 STL、看 Eigen 那种重模板库的源码,就能看懂他们为什么那么组织代码。
+
+## 包含模型:为什么模板都得写在头文件
+
+先回忆普通函数怎么分文件。声明放头文件 `add.h`,实现放 `add.cpp`,别处 `#include "add.h"` 就能用。编译器在调用点只看到声明,链接器再把调用绑到 `add.cpp` 里那份实现上。这套叫**分离编译**,是 C/C++ 的老传统。
+
+模板不按这套来。模板用的是**包含模型**(inclusion model):模板的定义必须在它被实例化的地方完整可见。您不能把函数模板的声明放头文件、定义放 `.cpp`,然后在别的翻译单元(translation unit, TU)里用它。原因是模板实例化发生在编译期,编译器要在调用点把 `T` 替换成具体类型、当场生成代码,这个生成过程需要看到完整的模板定义。
+
+```cpp
+// add.h —— 只放声明,行不行?
+template <typename T>
+T add(T a, T b);   // 只有声明
+```
+
+```cpp
+// add.cpp —— 放定义
+template <typename T>
+T add(T a, T b) { return a + b; }
+```
+
+```cpp
+// main.cpp
+#include "add.h"
+int main() {
+    return add(1, 2);   // 链接报错!undefined reference to `add<int>(int, int)`
+}
+```
+
+上面这套编译能过,链接会挂:`main.cpp` 里编译器看不到 `add` 的定义,没法实例化 `add<int>`,留下的只是一个未解析的符号引用;而 `add.cpp` 里因为没人「用到」`add`,编译器根本没实例化任何版本。两边对不上,链接器报 undefined reference。
+
+解决办法很朴素,把定义搬回头文件:
+
+```cpp
+// add.h —— 定义也在头文件里
+template <typename T>
+T add(T a, T b) { return a + b; }
+```
+
+这就是为什么几乎所有模板库都是头文件库,boost 是典型。代价咱们上一篇说过:每个 `#include` 它的翻译单元都要重新解析一遍模板定义,大项目编译起来就很慢。
+
+C++98 委员会其实想过治这个,搞了个 `export template` 想给模板也整一套分离编译,结果只有 EDG 一家实现,主流编译器全部放鸽子,C++11 干脆把 `export` 删了。所以到今天,包含模型还是模板的唯一现实选择。下一节讲的显式实例化,是包含模型下「省一点」的手段,不是真的分离编译。
+
+## 显式实例化:手动控制实例化点
+
+默认情况下,模板是**隐式实例化**:您在哪用到 `add<int>`,编译器就在那个翻译单元里生成一份 `add<int>` 的代码。十个翻译单元都用 `add<int>`,就生成十份,链接时再合并掉重复的。合并不要钱,但生成要钱——每个翻译单元都得做一遍替换和编译,这就是慢的根源。
+
+**显式实例化**(explicit instantiation)让您手动指定「在这里生成某个版本的代码」。
+
+显式实例化定义,长这样,以 `template` 关键字开头,跟一个不含 `template<>` 的具体签名:
+
+```cpp
+template <typename T>
+T add(T a, T b) { return a + b; }
+
+// 显式实例化定义:在这个翻译单元里,强制生成 add<double> 的代码
+template double add<double>(double, double);
+```
+
+这一行告诉编译器:不管这个翻译单元里有没有真的用到 `add<double>`,都给我生成一份。编译运行没问题:
+
+```bash
+$ g++ -std=c++17 explicit_inst.cpp -o explicit_inst && ./explicit_inst
+add(1.0, 2.0) = 3
+add(1, 2) = 3
+```
+
+跟它配对的是 `extern template` 声明。意思是「这个版本在别的翻译单元已经实例化了,我这儿就别再生成了,直接用别处的」:
+
+```cpp
+// 在某个 .cpp 里:显式实例化定义,真的生成代码
+//   template int add<int>(int, int);
+
+// 在其它 .cpp / .h 里:声明,不生成,链接时找别处的
+extern template int add<int>(int, int);
+```
+
+咱们跑一个两翻译单元的例子,看它能不能正常链接。
+
+```cpp
+// tu_a.cpp —— 这里隐式实例化 doubler<int>(因为 call_a 用了它)
+template <typename T>
+T doubler(T x) { return x * 2; }
+int call_a() { return doubler(21); }
+```
+
+```cpp
+// tu_b.cpp —— 声明 doubler<int> 在别处已实例化,本 TU 不再生成
+template <typename T>
+T doubler(T x) { return x * 2; }
+extern template int doubler<int>(int);
+int call_b() { return doubler(21); }
+```
+
+```cpp
+// main_ab.cpp
+#include <iostream>
+int call_a();
+int call_b();
+int main() {
+    std::cout << "call_a=" << call_a() << " call_b=" << call_b() << "\n";
+}
+```
+
+```bash
+$ g++ -std=c++17 tu_a.cpp tu_b.cpp main_ab.cpp -o main_ab && ./main_ab
+call_a=42 call_b=42
+```
+
+`tu_b` 里虽然也调用了 `doubler(21)`,但因为有 `extern template` 声明,它不生成 `doubler<int>` 的代码,而是等链接时用 `tu_a` 生成的那一份。链接通过,结果正确。
+
+这套机制真正的用武之地在库作者那边。标准库就大量用了这个套路:`std::basic_string<char>`、`std::vector<int>` 这些高频组合,libstdc++ 在自己的源文件里预先显式实例化好,然后在公开头文件里对用户代码声明 `extern template`。这样成千上万个用户的翻译单元就都不用重复实例化 `std::string` 的几十个成员函数了,编译时间和二进制体积都省下来一大块。您写自己的模板库时,对几个最常用的类型组合做同样处理,效果立竿见影。
+
+::: warning extern template 不是分离编译
+容易误会的一点:`extern template` 让您「不在本 TU 生成」。它确实让使用方 TU 不必把模板的完整定义也抄进来——只要声明加上 `extern template` 声明就够(前面 `tu_b` 那个例子把完整定义写出来其实多余,删掉定义只留声明,照样能编译链接)。但它的定位仍是「减少重复实例化」,不是把声明和定义真正分开:模板的实例化点必须存在(在某 TU 显式或隐式实例化),`extern template` 只是让别的 TU 复用它。模板真正的分离编译(像普通函数那样声明在 `.h`、实现只放一个 `.cpp`),至今没有干净的解法。
+:::
+
+## 函数模板不能偏特化:那个经典坑
+
+重头戏来了。类模板可以偏特化(partial specialization),变量模板(C++14)也可以偏特化,唯独**函数模板不能偏特化**。这不是哪个编译器的限制,是标准明确规定的。cppreference 在模板总览页写得很直白:偏特化只允许用在类模板和变量模板上。
+
+很多人第一次撞这个墙,是想给函数模板「针对指针类型写一个特殊版本」。直觉上既然类模板能写 `template <typename T> class Foo<T*>`,函数模板照葫芦画瓢应该也行:
+
+```cpp
+template <typename T>
+T identity(T x) { return x; }
+
+// 试图为 T* 偏特化 —— 编译报错!
+template <typename T>
+T identity<T*>(T* x) { return *x; }
+```
+
+编译器当场拦下:
+
+```text
+fn_partial.cpp:6:3: error: non-class, non-variable partial specialization
+      'identity<T*>' is not allowed
+    6 | T identity<T*>(T* x) { return *x; }
+      |   ^~~~~~~~~~~~
+```
+
+GCC 的措辞把规则说得很明白:只有类(class)和变量(variable)的偏特化是被允许的,函数的不行。
+
+为什么标准要这么规定?因为函数有**重载**,重载能干偏特化想干的所有事,而且更灵活。偏特化是「针对模板参数的某种模式提供一个特化版本」,重载是「针对参数类型提供一个独立函数」。两者目标重叠,标准就让函数走重载这条路,不让它再叠加一套偏特化语法,免得语义打架。
+
+那想给指针类型写特殊版本怎么办?用重载:
+
+```cpp
+template <typename T>
+T identity(T x) { return x; }            // 通用版本
+
+// 用重载给指针一个专门版本
+template <typename T>
+T identity(T* x) { return *x; }          // 指针版本
+
+int main() {
+    int v = 42;
+    identity(v);        // 调 T=int 版本,返回 42
+    identity(&v);       // 调 T=int 版本的指针重载,返回 42
+}
+```
+
+这里第二个 `identity` 是一个新的函数模板(参数是 `T*`),不是第一个的偏特化。调用 `identity(&v)` 时,编译器做重载解析,指针版本更匹配,胜出。
+
+要是逻辑分支更复杂,比如「指针走这条、整型走那条、其它走通用」,重载也能写,但会更啰嗦。这时候有两个更现代的工具,本卷第二部分会专门讲:`std::enable_if` 配合 SFINAE(C++11),以及 `if constexpr` 编译期分支(C++17)。前者靠「让某个重载在条件不满足时从候选里消失」来分流,后者直接在函数体里写编译期的 `if`。下面给个 `if constexpr` 的预告,您感受一下它能简洁到什么程度:
+
+```cpp
+template <typename T>
+void process(T x) {
+    if constexpr (std::is_pointer_v<T>) {
+        std::cout << "是指针,解引用:" << *x << "\n";
+    } else if constexpr (std::is_integral_v<T>) {
+        std::cout << "是整数:" << x << "\n";
+    } else {
+        std::cout << "其它类型\n";
+    }
+}
+```
+
+`if constexpr` 在编译期就把不成立的分支丢掉,不会留下「解引用一个非指针」这种编译错误。这是 C++17 之后处理「函数模板针对不同类型走不同逻辑」的首选方式,把以前要靠 SFINAE 写得很别扭的代码拉回了正常人类能读的样子。
+
+## 全特化是合法的,但要用对地方
+
+说了半天不能偏特化,那全特化呢?**函数模板的全特化是合法的**,语法是 `template<>` 开头,所有模板参数都钉死:
+
+```cpp
+template <typename T>
+const char* type_name() { return "unknown"; }
+
+// 全特化:int 版本
+template <>
+const char* type_name<int>() { return "int"; }
+
+// 全特化:double 版本
+template <>
+const char* type_name<double>() { return "double"; }
+```
+
+全特化有个坑要知道:它**不参与重载解析里「模板」那条路径**,而是作为一个普通函数插入候选。这意味着全特化的签名必须和主模板的某个实例化精确对应,差一点都不行。而且全特化一旦写了,它就「钉死」了那个具体版本,不会再随主模板变化。
+
+实际工程里,函数模板的全特化用得不多。多数情况下,直接写一个普通重载(非模板函数)比写全特化更省心,因为重载的规则更直观。全特化更适合「想保留模板身份、又想针对某个类型定制实现」的场景,比如给某个函数模板特化一个 `const char*` 版本去做字符串比较。
+
+::: warning 别在全特化上踩 ODR
+全特化的定义只能出现在一个翻译单元里,否则违反一次定义规则(ODR)。如果您把全特化写在头文件里又被多个 `.cpp` 包含,链接时会报重复定义。解决办法要么把它放进单个 `.cpp`,要么写成 `inline`。主模板的实例化没有这个问题(链接器会合并重复实例化),但全特化是普通函数,不享受这个待遇。
+:::
+
+## 一个有节制的小库长什么样
+
+把前面几节串起来,看一个写库时的典型组织方式。假设咱们要提供一个 `clamp` 函数模板,想让常用类型编译快、又不放弃泛型。
+
+头文件放模板定义,并对最常用的类型声明 `extern template`:
+
+```cpp
+// clamp.h
+template <typename T>
+const T& clamp(const T& v, const T& lo, const T& hi) {
+    if (v < lo) return lo;
+    if (hi < v) return hi;
+    return v;
+}
+
+// 预声明:int 和 double 版本在别处已实例化,包含本头文件的 TU 别再生成
+extern template const int&    clamp<int>(const int&, const int&, const int&);
+extern template const double& clamp<double>(const double&, const double&, const double&);
+```
+
+源文件里对这些类型做显式实例化定义:
+
+```cpp
+// clamp.cpp
+#include "clamp.h"
+
+// 真正在这里生成代码
+template const int&    clamp<int>(const int&, const int&, const int&);
+template const double& clamp<double>(const double&, const double&, const double&);
+```
+
+这样,所有包含 `clamp.h` 的翻译单元,用到 `clamp<int>` 时都不会自己实例化,而是链接到 `clamp.cpp` 里那份。别的类型(比如 `clamp<long>`)因为没有 `extern template` 声明,仍然按隐式实例化各自生成。常用类型省了,非常用类型也没被堵死。这就是标准库内部的典型做法,只是它处理的规模大得多。
+
+下一篇咱们进类模板。类模板的成员函数有「惰性实例化」的脾气,模板里还有依赖名和非依赖名的区分,这两件事合在一起,决定了类模板写起来跟函数模板是两种体验。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md b/documents/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md
new file mode 100644
index 000000000..88d7bca40
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/03-class-templates.md
@@ -0,0 +1,252 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 类模板是 STL 的基石。这一篇讲它写起来和函数模板的三个关键差异:成员函数类内还是类外定义、惰性实例化的脾气(没用到就不报错)、依赖名为什么要
+  typename 和 this-> 消歧义
+difficulty: intermediate
+order: 3
+platform: host
+prerequisites:
+- 模板导论:从一份代码配方说起
+- 函数模板深化:编译模型与那个不能偏特化的坑
+reading_time_minutes: 10
+related:
+- 模板特化与偏特化:模式匹配的艺术
+- 名字查找与 ADL:两阶段查找是怎么回事
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 类模板:成员、依赖名与惰性实例化
+---
+# 类模板:成员、依赖名与惰性实例化
+
+类模板是 STL 的基石,`std::vector`、`std::map`、`std::string`(其实是 `std::basic_string<char>`)全是类模板。会写函数模板不等于会写类模板,这两者有几个关键差异,正好是新手写类模板时反复栽跟头的地方。这一篇聚焦三个差异:成员函数写在类内还是类外、惰性实例化带来的「藏错」脾气、以及依赖名为什么需要 `typename` 和 `this->` 来消歧义。把这三个吃透,您写自己的容器、写策略类、读 STL 源码就不会卡在这些细节上。
+
+## 类模板长什么样
+
+从一个最小的栈开始,边写边看。
+
+```cpp
+template <typename T>
+class Stack {
+public:
+    void push(const T& value) { data_.push_back(value); }
+    void pop() { data_.pop_back(); }
+    const T& top() const { return data_.back(); }
+    bool empty() const { return data_.empty(); }
+private:
+    std::vector<T> data_;   // 用 vector 当底层存储
+};
+```
+
+`template <typename T>` 告诉编译器这是一个类模板,`T` 是类型参数。类里凡是出现 `T` 的地方,实例化时都会被替换成具体类型。`Stack<int>` 把 `T` 全换成 `int`,`Stack<std::string>` 换成 `std::string`,各自生成一个独立的类。
+
+上面把所有成员函数都写在类内部,这是最常见的写法,简洁。成员函数也可以写到类外面,但写法有个坑,下一节专门讲。
+
+类模板的成员函数本身也是模板(准确地说是「被模板化的函数」,templated function)。只有当某个成员函数被实际调用时,编译器才会为当前类型实例化它。这一点引出了类模板最重要的脾气。
+
+## 惰性实例化:没用到就不付钱
+
+类模板的成员函数,**只有真正被用到的那几个才会被实例化**。写一个 `Stack<Heavy>` 不会把 `Stack` 所有成员函数都生成一遍,只生成您实际调用的那些。这一条上一篇提过,这里用个更直白的例子看清楚。
+
+```cpp
+#include <iostream>
+
+template <typename T>
+struct Box {
+    T value;
+
+    void used_show() const {
+        std::cout << "value = " << value << "\n";
+    }
+
+    // 这个函数体里写了 T 上根本不存在的 nonexistent_field
+    // 只要没人调用它,编译器就不会实例化,也就不会报错
+    void unused_broken() const {
+        std::cout << value.nonexistent_field << "\n";
+    }
+};
+
+int main() {
+    Box<int> b{42};
+    b.used_show();   // 只用到这一个
+    return 0;
+}
+```
+
+`unused_broken` 里写的 `value.nonexistent_field`,在 `T=int` 时是 `int::nonexistent_field`,纯属胡扯。可这段代码编译通过、运行正常:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 lazy_inst.cpp -o lazy_inst && ./lazy_inst
+value = 42
+```
+
+原因就是惰性实例化。`main` 里只调用了 `used_show`,编译器只为 `Box<int>::used_show` 做实例化;`unused_broken` 从头到尾没人用,编译器连看都没看它一眼,里面写什么胡话都不报错。
+
+这条特性是 STL 的底气。`std::vector` 有几十个成员函数,您要是只用到 `push_back` 和 `size`,编译器就只实例化这两个,其它的 `insert`、`erase`、`emplace` 一概不生成。否则每种 `vector<X>` 都要把全部成员实例化一遍,编译时间和二进制体积会膨胀到不可接受。
+
+有利就有弊。惰性实例化的代价是**错误藏得深**。您在某个成员函数里写了个类型错误,只要测试用例没覆盖到那个函数,编译期就不会暴露。等哪天有人真的调用了它,可能已经是很久以后、在很远的代码里,排查起来就费劲了。所以写类模板时,最好显式地用一个「全类型自检」把所有成员都至少实例化一遍,或者写单元测试覆盖到每个成员函数。GCC 有个 `-Wtemplate-body` 之类的诊断能帮您抓一部分这类问题,新版 GCC 默认就会在模板体内对一些明显错误给出提示。
+
+## 类外定义成员函数:模板头不能少
+
+成员函数写到类外面,语法是 `template <...>` 头加上 `ClassName<T>::` 限定。两个都不能少。
+
+```cpp
+template <typename T>
+class Stack {
+public:
+    void push(const T& value);
+    const T& top() const;
+private:
+    std::vector<T> data_;
+};
+
+// 类外定义:必须带 template 头,且类名要带 <T>
+template <typename T>
+void Stack<T>::push(const T& value) {
+    data_.push_back(value);
+}
+
+template <typename T>
+const T& Stack<T>::top() const {
+    return data_.back();
+}
+```
+
+两个常见坑。一是忘了写 `template <typename T>` 头,编译器不知道 `Stack<T>` 里的 `T` 从哪来。二是类名忘了 `<T>`,写成 `void Stack::push(...)`,这是把 `Stack` 当成具体类了,而 `Stack` 只是模板名,必须带 `<T>` 才表示某个实例化。
+
+类外定义的好处是头文件清爽,坏处是模板的包含模型要求定义依然得在使用点可见,所以类外定义通常还是得写在头文件里(或者同一个头文件的末尾)。这跟普通类的「声明在 .h、实现在 .cpp」还是不一样。多数小型类模板直接把成员函数写在类内,省事;大型模板库(比如 STL 实现)会把成员函数拆到类外,并把它们放在同一个头文件或 `.tpp`(template implementation)文件里再被头文件 include。
+
+## 依赖名 vs 非依赖名:`typename` 消歧义
+
+这是类模板里最容易让人懵的一点。先记住两个名词:
+
+- **非依赖名**(non-dependent name):不依赖任何模板参数的名字。比如 `int`、`std::cout`,编译器在模板定义点就知道它是什么。
+- **依赖名**(dependent name):依赖某个模板参数的名字。比如 `T::value_type`,它的具体含义要等 `T` 确定了才知道。
+
+麻烦出在依赖名上。当编译器解析模板定义时,它还不知道 `T` 是什么,自然也就不知道 `T::value_type` 究竟是个类型,还是个静态成员变量,还是个别的东西。C++ 的规则是:**默认不假定它是类型**。如果您想让编译器把它当类型用,就得用 `typename` 关键字明确告诉它。
+
+```cpp
+template <typename Container>
+void print_first(const Container& c) {
+    typename Container::value_type first = *c.begin();
+    std::cout << "first = " << first << "\n";
+}
+```
+
+`Container::value_type` 在这里要当类型用(声明一个变量),前面必须加 `typename`。加上之后,编译运行没问题:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 typename_dis.cpp -o typename_dis && ./typename_dis
+first = 10
+```
+
+去掉 `typename`,GCC 直接拦下,报错信息把规则说得很清楚:
+
+```text
+typename_bad.cpp:3:5: error: need 'typename' before 'Container::value_type'
+      because 'Container' is a dependent scope
+    3 |     Container::value_type first = *c.begin();
+      |     ^~~~~~~~~~~
+```
+
+「`Container` is a dependent scope」,所以编译器不敢假定 `value_type` 是类型,得您显式声明。
+
+什么时候要加 `typename`?经验法则:当一个依赖限定符(带模板参数的 `::`)出现在需要类型的位置(声明变量、做类型转换、做返回类型、做模板类型参数),就要加 `typename`。C++20 之后(P0634)放宽了一处:在 type-only context(类型别名 `using`、函数返回类型、`new` 的类型、数据成员声明这几类位置)可以省略 `typename`,但局部变量声明这种位置依然要写。养成「依赖名当类型用就加 typename」的习惯最省心,不会出错。
+
+类似的还有 `template` 关键字消歧义。如果依赖名后面跟 `<`,编译器不知道这是模板还是小于号比较,这时要写 `T::template Foo<int>()` 明确告诉它 `Foo` 是模板。这条用得少,但碰到时知道有这个工具。
+
+## dependent base 和 `this->`
+
+类模板做继承时,会撞上另一个相关的坑。看这段:
+
+```cpp
+template <typename T>
+struct Base {
+    void helper() {}
+    int data = 7;
+};
+
+template <typename T>
+struct Derived : Base<T> {
+    void call() {
+        helper();   // 报错!
+    }
+};
+```
+
+`Derived` 继承自 `Base<T>`,在 `Derived::call` 里调用基类的 `helper()`。直觉上基类明明有 `helper`,应该能直接调。可编译器报错:
+
+```text
+dep_base.cpp:10:9: error: there are no arguments to 'helper' that depend on
+      a template parameter, so a declaration of 'helper' must be available
+   10 |         helper();
+      |         ^~~~~~
+```
+
+原因和 `typename` 那条是同一套逻辑。`Base<T>` 是个 dependent base,它的具体长相要等 `T` 确定才知道。编译器在解析 `Derived` 的定义时,不去 dependent base 里查找非依赖名(像 `helper` 这种不带 `T` 的名字),因为它怕 `T` 的某个特化里 `helper` 可能是个变量、或者根本不存在,查了反而可能查错。
+
+解决办法是让名字「带上依赖」,最常用的就是 `this->`:
+
+```cpp
+template <typename T>
+struct Derived : Base<T> {
+    int fetch() { return this->data; }   // this-> 让查找进入 dependent base
+    void call() { this->helper(); }
+};
+
+int main() {
+    Derived<int> d;
+    d.call();
+    std::cout << "fetch() = " << d.fetch() << "\n";   // 访问到 Base<T>::data = 7
+}
+```
+
+`this->` 告诉编译器「这是当前对象的成员,您到实例化的时候再去找」,问题解决。编译运行通过:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 dep_base_ok.cpp -o dep_base_ok && ./dep_base_ok
+fetch() = 7
+```
+
+另一个等价写法是显式限定 `Base<T>::helper()`,但这个写法会关闭虚函数的动态分派,所以如果 `helper` 是虚函数,别用 `Base<T>::`,用 `this->`。一般场景两者都行,`this->` 更通用。
+
+这条规则和下一篇要讲的「两阶段查找」是一回事的两面。两阶段查找要求编译器在模板定义阶段就对非依赖名做查找,而 dependent base 里的名字在定义阶段还看不到,所以编译器干脆不查。理解了这个动机,您就不会觉得 `this->` 是「多余的语法噪音」,它是为了让模板在两阶段查找的框架下行为可预测。
+
+## 静态成员:每个类型一份
+
+类模板可以有静态数据成员。和普通类的静态成员不同,类模板的静态成员**每个实例化类型各有一份独立实例**。
+
+```cpp
+template <typename T>
+struct Counter {
+    static int instances;   // 声明
+};
+
+// 定义(类外):要带 template 头
+template <typename T>
+int Counter<T>::instances = 0;
+
+// Counter<int>::instances 和 Counter<double>::instances 是两个不同的变量
+```
+
+`Counter<int>::instances` 和 `Counter<double>::instances` 是两个完全独立的静态变量,互不影响。这一点常被用来给每种类型做计数、做类型专属的缓存。
+
+这里要分清一个坑:类模板静态成员的类外定义(`template <typename T> int Counter<T>::instances = 0;` 这种)本身带 `template` 头,是弱符号(weak symbol),**可以**放在头文件里被多个翻译单元包含,链接器会自动合并,不冲突。真正「只能在一个翻译单元」的是**非模板**静态成员(普通类的 static 成员),它在头文件里被多 TU 包含才会重复定义。如果嫌类外定义麻烦,C++17 的 `inline` 静态成员可以直接在类内初始化:
+
+```cpp
+template <typename T>
+struct Counter {
+    static inline int instances = 0;   // C++17:inline 静态成员,类内初始化,免类外定义
+};
+```
+
+这是现代写法,省去了类外定义的麻烦。
+
+下一篇咱们进特化与偏特化。类模板能偏特化(这一点跟函数模板不一样),偏特化的「模式匹配」语义是模板里最有表达力的部分,`std::vector<bool>` 的特殊实现、type traits 的整套套路都建立在它上面。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md b/documents/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md
new file mode 100644
index 000000000..9b30347b8
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/04-specialization-partial.md
@@ -0,0 +1,215 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: 特化是模板最有表达力的部分。讲清全特化与偏特化的区别、编译器选「最特化」版本的优先级规则,以及两个经典应用:标准库 vector<bool>
+  为什么是偏特化、type_traits 整套 is_pointer/is_const 是怎么靠偏特化搭起来的
+difficulty: intermediate
+order: 4
+platform: host
+prerequisites:
+- 类模板:成员、依赖名与惰性实例化
+- 函数模板深化:编译模型与那个不能偏特化的坑
+reading_time_minutes: 10
+related:
+- 非类型模板参数:从整数到 C++20 的浮点与类类型
+- 名字查找与 ADL:两阶段查找是怎么回事
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 模板特化与偏特化:模式匹配的艺术
+---
+# 模板特化与偏特化:模式匹配的艺术
+
+模板最厉害的地方,不是「写一份套多种类型」,而是**给某些特定的类型或某一类类型,单独写一份不一样的实现**。这个机制叫特化(specialization)。特化分两种:全特化针对一个具体类型,偏特化针对一类类型模式。上一篇咱们提过函数模板不能偏特化,只有类模板和变量模板能偏特化,这一篇就把类模板的特化彻底讲透:全特化、偏特化、编译器选哪个版本的优先级规则,以及两个把偏特化用到极致的经典案例,标准库的 `std::vector<bool>` 和整个 `<type_traits>`。
+
+## 全特化:给一个具体类型单独写一份
+
+全特化(full specialization)是针对某一个**完全确定**的类型,提供一个专门的实现。语法是 `template<>` 开头,所有模板参数都钉死。
+
+```cpp
+// 主模板
+template <typename T>
+struct TypeSize {
+    static constexpr std::size_t value = sizeof(T);
+};
+
+// 全特化:针对 int 单独写一份
+template <>
+struct TypeSize<int> {
+    static constexpr std::size_t value = 4;   // 假设 32 位平台 int 是 4 字节
+};
+```
+
+有了这个全特化,`TypeSize<int>::value` 取的就是全特化里的 `4`,而 `TypeSize<double>::value` 走主模板算 `sizeof(double)`。全特化相当于「插队」:在编译器本该走主模板实例化 `TypeSize<int>` 的时候,看到有这么一个现成的全特化,就直接用全特化,不再生成主模板的版本。
+
+全特化有两个特点要记住。第一,全特化**不再是模板**,它是一个具体的类(或函数、变量),所有模板参数都已确定。这影响 ODR:全特化的定义只能出现在一个翻译单元里,否则重复定义。第二,全特化的签名必须和主模板的某个实例化精确对应,差一点都不行。
+
+## 偏特化:给一类类型模式单独写一份
+
+偏特化(partial specialization)针对的不是一个具体类型,而是**一类类型模式**。最常见的模式是「指针类型」「引用类型」。偏特化的语法是 `template <typename T>` 开头(注意它仍然是个模板,还有未绑定的 `T`),然后类名后面用 `<T*>` 这种带模式的写法。
+
+```cpp
+// 主模板
+template <typename T>
+struct TypeKind {
+    static const char* name() { return "generic (primary)"; }
+};
+
+// 偏特化:指针类型
+template <typename T>
+struct TypeKind<T*> {
+    static const char* name() { return "pointer (partial)"; }
+};
+
+// 偏特化:左值引用类型
+template <typename T>
+struct TypeKind<T&> {
+    static const char* name() { return "lvalue reference (partial)"; }
+};
+```
+
+注意偏特化和全特化的关键区别:偏特化的 `template <typename T>` 头里还有一个 `T`,它仍然是模板;而全特化是 `template<>` 空,所有参数都钉死。这个区别决定了偏特化能匹配「一类类型」,全特化只能匹配「一个类型」。
+
+跑一下看它怎么选:
+
+```cpp
+int main() {
+    std::cout << "double      : " << TypeKind<double>::name() << "\n";
+    std::cout << "double*     : " << TypeKind<double*>::name() << "\n";
+    std::cout << "double&     : " << TypeKind<double&>::name() << "\n";
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 spec_test.cpp -o spec_test && ./spec_test
+double      : generic (primary)
+double*     : pointer (partial)
+double&     : lvalue reference (partial)
+```
+
+(这里还没定义 `int*` 的全特化,所以 main 暂时不碰 `int*`;等下一节加上全特化,再看 `int*` 怎么选。)
+
+`double` 不匹配任何偏特化,走主模板;`double*` 匹配 `T*` 偏特化;`double&` 匹配 `T&` 偏特化。这是偏特化的核心能力:**根据类型的「形状」分流到不同的实现**,像一个编译期的类型 switch。
+
+## 优先级:全特化 > 偏特化 > 主模板
+
+上面那个 `int*` 的输出值得单独看。`int*` 既匹配 `T*` 偏特化(令 `T=int`),也匹配下面这个全特化:
+
+```cpp
+// 全特化:专门针对 int*
+template <>
+struct TypeKind<int*> {
+    static const char* name() { return "int* (full, wins over partial)"; }
+};
+```
+
+两个都能匹配,编译器选哪个?规则是**选更特化的那个**(more specialized)。全特化比偏特化更特化(它没有未绑定的参数),偏特化比主模板更特化。所以优先级是:**全特化 > 偏特化 > 主模板**。把上面的全特化定义加进去,再让 main 多打一行 `TypeKind<int*>::name()`,输出就是 `int* (full, wins over partial)`——`int*` 命中全特化,而不是走 `T*` 偏特化。
+
+如果有多个偏特化都能匹配,规则会变得微妙一点,编译器要比谁能「更具体」。比如 `T*` 和 `T const*` 两个偏特化,对 `const int*`,`T const*` 更具体,胜出。这套「更特化」的判定有一套形式化规则,平时写代码记住「编译器会选最贴合的那个」就够了,真碰到歧义编译器会报 ambiguous,您照着调整偏特化的模式就行。
+
+## 偏特化能匹配哪些模式
+
+偏特化的表达力在于它能匹配的「模式」很丰富。常见的有:
+
+- `T*`:指针类型
+- `T&` / `T&&`:引用类型
+- `const T*`、`volatile T`:带 cv 限定符的
+- `T[N]`:数组类型
+- `Foo<T>`、`Bar<T, U>`:某个具体模板的实例化
+- 甚至「模板模板参数」也能参与模式匹配
+
+把这些组合起来,偏特化几乎能识别任何「类型形状」。这正是 `<type_traits>` 能提供那么多类型查询的底层支撑,后面会看到。
+
+## 经典应用一:std::vector\<bool\> 的偏特化
+
+标准库里最出名的偏特化,是 `std::vector<bool>`。它不是 `std::vector<T>` 用 `T=bool` 实例化出来的普通版本,而是库专门写的一个偏特化。目的是让一个 `bool` 只占一个 bit,而不是一个字节,省内存。
+
+```cpp
+// 标准库内部大致是这个意思(简化示意)
+template <typename T, typename Alloc = std::allocator<T>>
+class vector { /* 普通实现,一个 T 一份存储 */ };
+
+template <typename Alloc>
+class vector<bool, Alloc> { /* 偏特化:位压缩,一个 bool 一个 bit */ };
+```
+
+`vector<bool>` 的偏特化有个肉眼可见的副作用:它的 `operator[]` 返回的不是 `bool&`,而是一个**代理对象**(proxy object)`std::vector<bool>::reference`。原因是位压缩后,您没法返回「一个 bit 的引用」(内存最小寻址单位是字节),只能返回一个模拟 `bool&` 行为的临时对象。跑一下能直接看到这个差异:
+
+```cpp
+#include <iostream>
+#include <type_traits>
+#include <vector>
+
+int main() {
+    std::cout << std::boolalpha;
+    // vector<bool> 的 reference 是代理类,不是 bool&
+    std::cout << "vector<bool>::reference is bool&?   "
+              << std::is_same_v<std::vector<bool>::reference, bool&> << "\n";
+    // 普通 vector 的 reference 就是元素引用
+    std::cout << "vector<char>::reference is char&?  "
+              << std::is_same_v<std::vector<char>::reference, char&> << "\n";
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 vecbool.cpp -o vecbool && ./vecbool
+vector<bool>::reference is bool&?   false
+vector<char>::reference is char&?  true
+```
+
+这个代理 `reference` 给 `vector<bool>` 惹了不少争议。它让 `vector<bool>` 不完全满足「序列容器」的要求(因为 `reference` 不是真正的元素引用),也让一些通用代码在它上面行为异常,比如 `auto& x = vec[0];` 在 `vector<bool>` 上**直接编不过**(代理 `reference` 是个右值临时对象,绑不了非 const 左值引用);就算改成 `auto x = vec[0];`,拿到的也是代理对象、不是 `bool`,某些操作会出乎意料。委员会多次讨论要不要把它移出标准、改成 `dynamic_bitset` 之类的独立设施,但因为它已经到处在用,改动代价太大,就这么一直留着。这是偏特化的一个「反面教材」:偏特化可以完全重新定义实现,但代价是它可能不再满足主模板隐含的接口契约,使用者会踩坑。
+
+## 经典应用二:type_traits 的整套套路
+
+`<type_traits>` 里的 `std::is_pointer`、`std::is_const`、`std::is_reference` 这些查询,底层全是「主模板返回 false + 偏特化命中返回 true」的套路。咱们手写一个 `is_pointer` 就能看穿它:
+
+```cpp
+// 主模板:默认不是指针
+template <typename T>
+struct is_pointer {
+    static constexpr bool value = false;
+};
+
+// 偏特化:指针类型才命中
+template <typename T>
+struct is_pointer<T*> {
+    static constexpr bool value = true;
+};
+```
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 is_ptr.cpp -o is_ptr && ./is_ptr
+is_pointer<int>::value       = false
+is_pointer<int*>::value      = true
+is_pointer<int**>::value     = true
+is_pointer<int&>::value      = false
+```
+
+`int` 走主模板,`value=false`;`int*` 命中 `T*` 偏特化,`value=true`;`int**` 也命中(`T=int*`);`int&` 是引用不是指针,走主模板,`false`。
+
+这就是 `std::is_pointer` 的全部秘密。标准库的 `is_pointer` 比这个多一点(还要处理指向成员的指针、cv 限定等边界),但核心思路就是这个主模板+偏特化的 pattern。`is_const`(`const T*` 不算,`T const` 算)、`is_reference`(`T&` 和 `T&&`)、`is_array`(`T[N]`)全是同一套办法:主模板给个默认值,偏特化针对目标模式覆盖。
+
+理解了这个套路,您就能自己写类型查询了。比如想查「是不是函数指针」,就写主模板默认 false,偏特化 `R(*)(Args...)` 命中 true。整个 `<type_traits>` 就是几百个这样的偏特化堆出来的。后面第二部分讲 SFINAE,第三部分讲 concepts,都建立在您理解「靠偏特化做编译期类型判断」这件事之上。
+
+## 偏特化的几条限制
+
+最后把偏特化的边界讲清楚,免得踩坑。
+
+**函数模板不能偏特化**。这条上一篇专门讲过,标准只允许类模板和变量模板(C++14)偏特化。函数要分流走重载、走 `if constexpr`、走 SFINAE。
+
+**偏特化通常写在命名空间作用域**。绝大多数偏特化都放在命名空间级别。C++11 之后(CWG 727)成员类模板的偏特化也可以出现在外层类的作用域里,但写法绕、用得少,平时就把偏特化放命名空间,省心。
+
+**偏特化可以完全重新定义实现**。偏特化不必和主模板有相同的成员,它可以彻底长一个样。但这也意味着,使用者通过主模板名字访问时,得保证偏特化提供了对应的成员,否则换个类型就编不过。`vector<bool>` 就是这么干的,它的成员和普通 `vector` 几乎一样但语义有微妙差别。
+
+**偏特化和全特化的 ODR 不同**。偏特化仍然是模板,它的实例化在多个翻译单元里会自动合并,不违反 ODR。全特化是具体实体,定义只能在一个翻译单元,或者标 `inline`。
+
+下一篇咱们进非类型模板参数。偏特化的模式匹配里,非类型参数是个重要角色,`std::array<T, N>` 的 `N` 就是它,而 C++20 又把非类型参数能接受的类型大幅放宽了,从只能用整数和指针,扩展到浮点甚至满足条件的类类型。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md b/documents/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md
new file mode 100644
index 000000000..4801a6355
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/05-non-type-parameters.md
@@ -0,0 +1,191 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 非类型模板参数让一个「值」也能被参数化,array<T,N> 里的 N 就是它。讲清它能用什么类型、C++17 的 auto 推导、C++20
+  把它放宽到浮点和满足 structural 条件的类类型,以及哪些实参算「同一个」实例化
+difficulty: intermediate
+order: 5
+platform: host
+prerequisites:
+- 模板特化与偏特化:模式匹配的艺术
+- 类模板:成员、依赖名与惰性实例化
+reading_time_minutes: 9
+related:
+- 名字查找与 ADL:两阶段查找是怎么回事
+- 模板友元与 Barton-Nackman:隐藏友元技巧
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+- 编译期计算
+title: 非类型模板参数:从整数到 C++20 的浮点与类类型
+---
+# 非类型模板参数:从整数到 C++20 的浮点与类类型
+
+前面几篇咱们参数化的都是「类型」,`typename T` 占位一个类型。模板还能参数化另一种东西:**一个编译期已知的值**。`std::array<T, N>` 里的 `N`、`std::bitset<N>` 里的 `N`,都是这种参数,叫非类型模板参数(non-type template parameter)。这一篇讲它能接受什么类型的值,C++17 的 `auto` 怎么让它更灵活,C++20 又怎么大刀阔斧地把它从「只能用整数和指针」放宽到「浮点甚至类类型」,以及哪些实参算「同一个」实例化。C++20 这次放宽是非类型参数诞生以来最大的一次升级,直接催生了 fixed_string、编译期常量对象这些新玩法。
+
+## 非类型参数是什么:参数化一个值
+
+类型参数 `typename T` 占位的是一个类型,非类型参数占位的是一个**具体的值**。最经典的形式是整数:
+
+```cpp
+template <typename T, std::size_t N>
+struct array {
+    T data[N];   // N 是编译期就知道的大小
+};
+```
+
+这里 `N` 是一个非类型参数,它的「类型」是 `std::size_t`,实例化时您要给它一个具体的值,比如 `array<int, 8>`,`N` 就是 8。`N` 必须在编译期就能确定,因为编译器要用它生成 `int data[8]` 这个数组类型,这是类型的一部分,运行时变不了。
+
+非类型参数能用哪些类型?在 C++17 之前,规则挺窄:整数类型(各种 `int`、`char`、`bool`)、枚举、指针、引用,还有指向成员的指针。浮点数不行,普通的类对象也不行。这个限制催生了一堆绕路写法,C++20 才把它们扶正。
+
+## 整数和指针:最传统的用法
+
+整数非类型参数最常见,固定大小的容器、位集、编译期常量都靠它。
+
+```cpp
+template <int Lower, int Upper>
+struct Range {
+    static constexpr int lo = Lower;
+    static constexpr int hi = Upper;
+};
+
+// 实参必须是编译期常量
+constexpr int kMin = 10;
+Range<kMin, kMin + 100> r;   // OK:实参都是常量表达式
+// Range<some_runtime_value, 100> r2;   // 编译报错:实参不是常量
+```
+
+指针和引用也能做非类型参数,但实参必须是「编译期能确定地址」的对象,比如静态变量的地址、函数地址:
+
+```cpp
+template <int* P>
+struct PtrHolder {
+    static int* get() { return P; }
+};
+
+int global_var = 42;
+PtrHolder<&global_var> ph;   // OK:全局变量地址编译期已知
+```
+
+这条「实参必须是常量表达式」的要求,是非类型参数和普通函数参数最根本的区别。普通函数参数运行时传值,非类型参数在编译期就得是确定值。
+
+## C++17 的 auto:让类型自动推导
+
+C++17 给非类型参数加了一个很实用的东西:`auto` 占位符。以前您得写明非类型参数的类型,`template <int N>`;现在可以写 `template <auto N>`,让编译器根据实参推导。
+
+```cpp
+template <auto N>
+struct Constant {
+    static constexpr auto value = N;
+};
+```
+
+跑一下看它的灵活:
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 ntp_auto.cpp -o ntp_auto && ./ntp_auto
+Constant<42>::value = 42
+Constant<true>::value = 1
+Constant<'a'>::value = a
+```
+
+`Constant<42>` 推出 `N` 是 `int`,`Constant<true>` 推出 `bool`,`Constant<'a'>` 推出 `char`。一个模板参数,装下了不同类型的值。这在写通用元函数时省去了一堆 `template <typename T, T N>` 的样板,以前要两个参数(类型 + 值),现在一个 `auto` 搞定。
+
+## C++20 的两大放宽:浮点和类类型
+
+C++20 对非类型参数做了一次大手术,放开了两块以前不让碰的禁区。
+
+**浮点数**。C++20 之前,浮点数不能做非类型参数,原因是浮点的等价性判定有精度坑(两个编译期浮点值是不是「相等」很难定义干净)。C++20 把规则定好后,放开了:
+
+```cpp
+template <double Pi>
+struct CircleArea {
+    static constexpr double compute(double r) { return Pi * r * r; }
+};
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_float.cpp -o ntp_float && ./ntp_float
+area(2.0) = 12.5664
+```
+
+`CircleArea<3.14159265>` 把圆周率当编译期常量烤进类型里。以前这种事只能靠 `constexpr double pi = ...` 的普通变量,现在能直接进模板参数,意味着不同的 `Pi` 值会生成不同的类型,您可以让类型本身就携带精度信息。
+
+**类类型(structural class)**。这是 C++20 放宽里更有想象力的一块。以前类对象不能做非类型参数,因为对象有构造、有地址、有生命周期,没法简单比较等价。C++20 引入了 **structural type** 的概念:满足几个条件的类类型,可以当非类型参数用。条件是:它得是个 **literal class type**(字面类,只要有 constexpr 构造函数就行,**不要求是聚合 aggregate**)、所有基类和非静态数据成员都得是 `public` 且非 `mutable`、且基类和成员本身也是 structural。简单说就是一个「全公开、成员不可变的值类型」,编译器能用它的成员逐一比较等价。
+
+这里有个容易混的点:literal class 和 aggregate 不是一回事。aggregate 禁止用户声明构造函数,literal class 只要求有 constexpr 构造函数(可以有用户构造)。structural 要的是 literal class,所以**带 constexpr 构造函数的类(哪怕不是 aggregate)也能做非类型参数**——下一节要讲的 fixed_string 正是靠这个:它有 constexpr 构造拷贝 `char` 数组,不是 aggregate,但符合 structural。
+
+```cpp
+struct Point {      // structural:public、非 mutable、成员都是 structural(int);也是 literal class
+    int x;
+    int y;
+};
+
+template <Point P>
+struct Pixel {
+    static constexpr Point pos = P;
+};
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_struct.cpp -o ntp_struct && ./ntp_struct
+origin: (0,0)
+corner: (3,4)
+```
+
+`Pixel<Point{3, 4}>` 把一个二维坐标烤进了类型。这个能力的招牌应用是 **fixed_string**:用一个 structural 的字符串类(带 constexpr 构造、内部是 `char` 数组),把字符串包进类型里,实现「类型里带字符串」。日志库给每个日志级别一个 fixed_string 标签、网络库把 URL 路径当类型,都建立在这上面。注意字符串字面量**从来不能**直接做非类型参数(C++20 也一样),它的类型是 `const char[N]`,会 decay 成指针,不同字面量地址不同,等价性没法处理;C++20 的突破是允许用 structural 的 fixed_string 把字符串**包起来**当 NTTP,而不是字面量直接上。
+
+## 等价性:哪些实参算「同一个」
+
+非类型参数有个绕不开的问题:两个实参什么时候算「同一个实例化」?规则叫 template-argument-equivalent。对整数,看值相等:`1 + 1` 和 `2` 是等价的,`Tag<1 + 1>` 和 `Tag<2>` 是同一个类型。
+
+```cpp
+#include <iostream>
+#include <type_traits>
+
+template <int N>
+struct Tag {};
+
+int main() {
+    std::cout << std::boolalpha;
+    std::cout << "Tag<1+1> is Tag<2>? " << std::is_same_v<Tag<1 + 1>, Tag<2>> << "\n";
+    std::cout << "Tag<2*3> is Tag<6>? " << std::is_same_v<Tag<2 * 3>, Tag<6>> << "\n";
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 ntp_equiv.cpp -o ntp_equiv && ./ntp_equiv
+Tag<1+1> is Tag<2>? true
+Tag<2*3> is Tag<6>? true
+```
+
+程序输出 `true`,就证明 `Tag<1+1>` 和 `Tag<2>` 是同一个类型。这条规则的实际意义是:不管写 `1+1` 还是 `2`,编译器不会重复实例化两份 `Tag<2>`,它认得这是同一个东西。
+
+对指针和引用,等价性看「指向同一个对象或函数」。对浮点(C++20)和 structural 类类型(C++20),等价性看值的位级或成员级比较。浮点这里有个要注意的点:两个浮点实参只有「位级相同」才算等价,不是「数值相等」。最典型的反例是 `Circle<0.0>` 和 `Circle<-0.0>`:`0.0 == -0.0` 数值上相等,但位表示不同(符号位不同),所以是**两个不同的类型**。这避免了精度模糊带来的歧义,也意味着传浮点模板参数时,字面量要写精确。
+
+## 非类型参数的典型用途
+
+把非类型参数的常见用法归个类,您碰到时就知道往哪想。
+
+固定大小的容器。`std::array<T, N>`、`std::bitset<N>`、本卷最后的 `fixed_vector<T, N>` 综合项目,都用整数非类型参数把大小烤进类型。好处是存储在栈上、无动态分配、大小类型安全(不同 `N` 的 `array` 是不同类型,编译器帮您防误用)。
+
+编译期常量。把物理常量、配置值、版本号当非类型参数烤进类型,本篇的 `CircleArea<3.14>` 就是这类。类型携带了值,可以实现编译期的多态分发。
+
+C++20 之后的字符串与对象。fixed_string、编译期坐标、编译期配置对象,都靠 structural class non-type parameter。这是 C++20 给模板元编程开的新窗口,vol3 元编程部分会专门展开。
+
+## 几个坑
+
+实参必须是常量表达式。这是铁律,运行时的值传不进去,会编不过。
+
+字符串字面量从来不能直接做非类型参数(C++20 也一样)。`Foo<"hello">` 不行,因为字符串字面量 decay 成指针后等价性没法处理。C++20 的解法是用 structural 的 fixed_string 类把字符串包一层,vol3 会讲。
+
+浮点实参的等价性是位级比较。`Circle<0.0>` 和 `Circle<-0.0>` 数值相等但位级不同,是两个类型;反过来 `Circle<3.14>` 和 `Circle<3.14000>` 因为词法折叠后位级完全相同,反而是同一个类型。判据是位级,不是数值,也不是写法。
+
+下一篇咱们进两阶段名字查找和 ADL。模板里的名字查找跟普通代码完全不是一个套路,它分两个阶段进行,这个机制直接解释了前面几篇里 `typename`、`this->`、隐藏友元这些看似奇怪的规则为什么必须存在。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md b/documents/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md
new file mode 100644
index 000000000..5d236896b
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/06-name-lookup-and-adl.md
@@ -0,0 +1,165 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 模板里的名字查找跟普通代码完全不同,它分两个阶段。讲清两阶段查找、依赖名与非依赖名、ADL(实参依赖查找),以及为什么前面几篇的 typename、this->、隐藏友元那些看似奇怪的规则必须存在
+difficulty: intermediate
+order: 6
+platform: host
+prerequisites:
+- 类模板:成员、依赖名与惰性实例化
+- 非类型模板参数:从整数到 C++20 的浮点与类类型
+reading_time_minutes: 9
+related:
+- 模板友元与 Barton-Nackman:隐藏友元技巧
+- 模板特化与偏特化:模式匹配的艺术
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 名字查找与 ADL:两阶段查找是怎么回事
+---
+# 名字查找与 ADL:两阶段查找是怎么回事
+
+写普通代码时,您用一个名字,编译器在当前位置查一查,找到就用。模板里这一套不灵。模板的名字查找分两个阶段进行,一个在模板定义的时候,一个在模板实例化的时候。这套机制叫两阶段查找(two-phase lookup),它直接解释了前面几篇里那些看起来很奇怪的规则:`typename` 为什么不能省、`this->` 为什么必须有、隐藏友元为什么有用。这一篇把两阶段查找、依赖名和非依赖名、ADL 一次讲透,讲完之后,模板里那些「莫名其妙」的报错,您都能找到根源。
+
+## 普通代码的名字查找:一次查完
+
+先看普通函数。在普通函数里用到一个名字,编译器在函数定义点做一次普通查找(ordinary lookup),从内向外一层层命名空间找,找到候选集就停下来。
+
+```cpp
+void helper(int) {}
+
+void caller() {
+    helper(42);   // 编译器在 caller 定义点查 helper,找到 ::helper(int)
+}
+```
+
+这套很直觉。普通查找只看「定义点之前」可见的名字,定义点之后才声明的同名函数,它不看。
+
+## 模板不一样:分两阶段
+
+模板把这件事拆成了两个阶段。
+
+**第一阶段**(模板定义阶段):编译器解析模板定义时,对所有**非依赖名**做查找和绑定。这时候 `T` 还不知道是什么,所以依赖 `T` 的名字没法查,先放一边。
+
+**第二阶段**(模板实例化阶段):模板被某个具体类型实例化时,`T` 已经确定了,编译器再对**依赖名**做查找,这一阶段的主要工具是 ADL(实参依赖查找)。
+
+为什么要分两阶段?因为模板定义的时候,编译器根本不知道 `T` 会是什么,自然不知道 `T::value_type` 是个类型还是个变量,也不知道 `foo(t)` 里的 `foo` 该去哪个命名空间找。所以它把能查的(非依赖名)先查了,不能查的(依赖名)留到实例化时再说。
+
+来看一个能直接看出两阶段效果的经典例子。
+
+```cpp
+#include <iostream>
+
+// 模板定义之前就存在的 helper
+void helper(int) { std::cout << "::helper(int), defined before template\n"; }
+
+template <typename T>
+void call_it(T x) {
+    helper(x);   // helper 是非依赖名,第一阶段(定义点)查找并绑定
+}
+
+// 模板定义之后才加的 helper
+void helper(double) { std::cout << "::helper(double), defined after template\n"; }
+
+int main() {
+    call_it(3.14);   // T=double。直觉上会不会期望走 helper(double)?
+    return 0;
+}
+```
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 twophase.cpp -o twophase && ./twophase
+::helper(int), defined before template
+```
+
+`call_it(3.14)` 实际走的是 `helper(int)`,不是定义在后面的 `helper(double)`。原因就是两阶段:`helper` 这个名字是非依赖名(不带 `T`),在第一阶段(模板定义点)就被查找并绑定到当时唯一可见的 `helper(int)`。定义在模板后面的 `helper(double)`,第一阶段看不到;第二阶段只对依赖名做 ADL,`double` 是内置类型没有关联命名空间,ADL 引入不了新候选。于是 `helper(x)` 永远绑定到 `helper(int)`,`3.14` 被截断成 `3` 传进去。
+
+注意这里和普通函数其实没有差异:非依赖名的查找都在「定义点」完成,不管 `call_it` 是模板还是普通函数,只要它定义在 `helper(double)` 之前,就只能看到 `helper(int)`。两阶段查找真正和普通函数不一样的地方,在依赖名的第二阶段——下一节讲 ADL 时会看到,模板能通过实参类型在实例化点找到定义点根本看不到的函数,这才是两阶段查找的独门本事。
+
+## 依赖名 vs 非依赖名
+
+这条线决定一个名字在哪个阶段查,值得单独强调。
+
+非依赖名(non-dependent name),不带任何模板参数的名字。比如 `helper`、`std::cout`、`int`。它们在第一阶段查。
+
+依赖名(dependent name),直接或间接依赖某个模板参数的名字。比如 `T::value_type`、`x.foo()`(当 `x` 的类型是 `T`)、`foo(t)`(当 `t` 的类型依赖 `T`)。它们在第二阶段查,主要靠 ADL。
+
+一个调用 `foo(t)` 是不是依赖,看参数 `t` 的类型是否依赖 `T`。如果 `t` 是 `T` 类型,那 `foo(t)` 是依赖调用,第二阶段会通过 ADL 在 `T` 所在的命名空间里找 `foo`。这是 ADL 发挥作用的入口。
+
+## typename 和 this->:两阶段的直接后果
+
+回头看前面几篇的两条规则,它们都是两阶段查找的直接后果。
+
+`typename` 消歧义。`T::value_type` 这种依赖名,编译器在第一阶段(定义点)不知道 `T` 是什么,自然不敢假定 `value_type` 是类型。它默认把依赖的限定名当成变量或函数,除非您用 `typename` 显式声明「这是个类型」。这是两阶段在定义点「查不动」的必然结果。
+
+`this->` 访问 dependent base 成员。基类是 `Base<T>` 时,它的成员在第一阶段也看不到(因为 `Base<T>` 的具体长相要等 `T` 确定)。编译器在第一阶段不查 dependent base 里的非依赖名,所以直接写 `helper()` 找不到基类的 `helper`,要用 `this->helper()` 把查找推迟到第二阶段(实例化时,`this` 的类型已知,基类成员可见)。
+
+理解了这两条规则都源于两阶段查找,您就不会再觉得它们是「多余的语法」,它们是让模板行为可预测的必要机制。没有两阶段,模板的查找结果会随着实例化点的上下文剧烈变化,谁也写不出可靠的模板库。
+
+## ADL:实参依赖查找
+
+ADL(argument-dependent lookup)是两阶段第二阶段查依赖名的核心工具。规则说起来朴素:**调用一个函数时,除了普通查找,编译器还会在「实参类型所在的命名空间」里找候选函数**。
+
+```cpp
+#include <iostream>
+
+namespace geo {
+    struct Point { int x; int y; };
+    void draw(const Point&) { std::cout << "geo::draw(Point)\n"; }
+}
+
+int main() {
+    geo::Point p{1, 2};
+    draw(p);   // 既没写 geo:: 限定,也没 using namespace geo
+    return 0;
+}
+```
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 adl.cpp -o adl && ./adl
+geo::draw(Point)
+```
+
+`main` 里调用 `draw(p)`,既没有 `geo::` 限定,也没有 `using namespace geo`。普通查找在全局命名空间找不到 `draw`,本该报错。但 ADL 介入了:实参 `p` 的类型是 `geo::Point`,它在 `geo` 命名空间里,于是编译器去 `geo` 里找 `draw`,找到了 `geo::draw`。调用成功。
+
+ADL 的别名 Koenig lookup,得名于 Andrew Koenig,他最早提出了这套规则。它的设计动机是:操作某个类型的函数,通常就定义在那个类型所在的命名空间里。`std::cout << x` 能工作,靠的就是 ADL 在 `x` 的类型所在命名空间里找 `operator<<`。如果没有 ADL,您每次都得写完整的限定,泛型代码根本没法写。
+
+## ADL 的工程意义:运算符和泛型算法
+
+ADL 不是花架子,它是现代 C++ 几个关键惯用法的支柱。
+
+**运算符查找**。`std::cout << myObj` 之所以能找到 `myObj` 类型对应的 `operator<<`,全靠 ADL。`myObj` 的类型在哪个命名空间,ADL 就去那个命名空间找 `operator<<`。这是运算符重载能跨命名空间工作的根本。
+
+**swap 惯用法**。泛型代码里交换两个值,标准写法是:
+
+```cpp
+using std::swap;
+swap(a, b);   // 不写 std::swap(a,b),而是先 using std::swap 再裸调
+```
+
+`using std::swap` 把 `std::swap` 引入候选,然后裸调 `swap(a, b)`。这样如果 `a` 的类型在某个命名空间里提供了更高效的 `swap`(比如 `ns::swap`),ADL 会找到它并优先用;如果没有,退化到 `std::swap`。这就是为什么标准库到处用 `using std::swap; swap(a,b);` 而不是直接 `std::swap(a,b)`,给自定义类型留优化空间。`std::begin`、`std::end`、`std::size`、`std::data` 这一组也是同一思路。
+
+**「可被发现」的设计**。您想让某个函数被泛型算法找到,把它放进实参类型所在的命名空间就行,ADL 会自动发现。这是 C++ 命名空间设计里很重要的一环:函数跟着它操作的类型走,而不是全局散落。
+
+## 两阶段查找的坑和编译器差异
+
+两阶段查找有几个坑,加上历史包袱,值得说一下。
+
+**「定义点之后加的重载模板看不到」**。前面 `helper` 的例子就是这个坑:在模板定义之后才声明的同名重载,模板内部的非依赖名调用看不到它们。解决办法要么把重载声明挪到模板前面,要么让调用变成依赖的(让 ADL 能介入)。
+
+**MSVC 的历史包袱**。很长一段时间,MSVC 的编译器**不严格实现两阶段查找**,它把所有查找都推迟到实例化阶段一次性做。这导致一些在 GCC、Clang 上会报错的代码(比如违反两阶段规则的),在 MSVC 上能编译通过;反之也有。这种「MSVC 能过、别处炸」或「别处能过、MSVC 炸」的差异,是跨平台模板库开发的经典痛点。MSVC 后来加了 `/permissive-` 开关来严格遵循两阶段,现代项目基本都会开,但老代码的坑还在。
+
+**ADL 的意外命中**。ADL 有时会找到您没想到的函数。比如某个类型恰好在某个命名空间里有个同名函数,ADL 可能把它卷进来,导致二义性或调到错误实现。隐藏友元(hidden friends,下一篇讲)就是治这个病的:把运算符定义成类的隐藏友元,让它只对实参类型精确匹配时才被 ADL 发现,避免污染全局重载池。
+
+下一篇咱们进模板友元和 Barton-Nackman 技巧。隐藏友元、奇递归模板里的友元注入,都是建立在您理解了 ADL 之后才能讲清的东西。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md b/documents/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md
new file mode 100644
index 000000000..16def62b2
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/07-friends-and-barton-nackman.md
@@ -0,0 +1,186 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+description: 上一篇讲了 ADL,这一篇讲它最漂亮的搭档:隐藏友元和 Barton-Nackman 技巧。在类模板里把 operator== 定义成友元,每个实例化自动获得专属于该类型的运算符,既不污染全局重载池,又能被
+  ADL 精确发现
+difficulty: intermediate
+order: 7
+platform: host
+prerequisites:
+- 名字查找与 ADL:两阶段查找是怎么回事
+- 类模板:成员、依赖名与惰性实例化
+reading_time_minutes: 7
+related:
+- 别名模板与 using 声明:给类型起个短名字
+- CRTP:用奇递归模板做静态多态
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 泛型
+title: 模板友元与 Barton-Nackman:隐藏友元技巧
+---
+# 模板友元与 Barton-Nackman:隐藏友元技巧
+
+上一篇咱们讲了 ADL,这一篇讲它最漂亮的搭档:**隐藏友元**(hidden friends)和 **Barton-Nackman 技巧**。核心想法一句话:把运算符(比如 `operator==`、`operator<<`)定义成类模板的**友元,并且直接在类内部给出定义**。这样每个实例化会自动生成一个专属于该类型的非模板运算符函数,它既不污染全局重载池,又能被 ADL 在精确类型匹配时发现。这是现代 C++ 给自定义类型配运算符的推荐姿势,标准库自己也大量这么用。
+
+## 友元:快速回顾
+
+友元(friend)是 C++ 给某个外部函数或类「访问自己私有成员」的权限。友元不是类的成员,它是外部实体,只是被特许能碰到私有部分。
+
+```cpp
+class Account {
+    int balance_;
+    friend void audit(const Account&);   // audit 不是成员,但能访问 balance_
+public:
+    explicit Account(int b) : balance_(b) {}
+};
+
+void audit(const Account& a) {
+    std::cout << "balance = " << a.balance_ << "\n";   // 能访问私有,因为是友元
+}
+```
+
+普通友元是「声明在类里,定义在类外」。模板友元在此基础上玩出了新花样,下面一步步看。
+
+## 友元注入:在类模板里定义友元
+
+关键的一步来了。友元不仅可以声明在类里、定义在类外,还可以**直接在类内部给出定义**。当这个类是模板时,类内定义的友元会随着类的实例化,为每个具体类型生成一个独立的函数。这个函数有个特殊性质:**它不在命名空间作用域可见,只能通过 ADL 发现**。
+
+```cpp
+template <typename T>
+class Box {
+    T v_;
+public:
+    constexpr Box(T v) : v_(v) {}
+
+    // 类内友元定义:不是函数模板,是「随 Box<T> 实例化而生成的非模板函数」
+    friend constexpr bool operator==(const Box& a, const Box& b) {
+        return a.v_ == b.v_;
+    }
+};
+```
+
+注意这里的 `operator==` 没有独立的 `template <...>` 头,它写在 `Box` 类内部,参数类型用 `const Box&`(在类内部 `Box` 就是 `Box<T>` 的简写)。编译器实例化 `Box<int>` 时,会生成一个 `bool operator==(const Box<int>&, const Box<int>&)` 的具体函数;实例化 `Box<double>` 时,生成另一个 `bool operator==(const Box<double>&, ...)`。这两个函数互不相同,各管各的类型。
+
+这个手法叫 **Barton-Nackman 技巧**,得名于 John Barton 和 Lee Nackman 1994 年的书《Scientific and Engineering C++》,他俩最早系统化地用了这套写法。它解决的核心问题是:给类模板自动配上运算符,又不用为每种类型写一遍特化。
+
+## 完整例子:配齐 == 和 <<
+
+来看一个能跑的完整例子,给 `Box<T>` 配上 `==` 和 `<<`。
+
+```cpp
+#include <iostream>
+
+template <typename T>
+class Box {
+    T v_;
+public:
+    constexpr Box(T v) : v_(v) {}
+
+    friend constexpr bool operator==(const Box& a, const Box& b) {
+        return a.v_ == b.v_;
+    }
+    friend std::ostream& operator<<(std::ostream& os, const Box& b) {
+        return os << "Box{" << b.v_ << "}";
+    }
+};
+
+int main() {
+    Box<int> x{1}, y{1}, z{2};
+    Box<double> p{1.5}, q{1.5};
+    std::cout << std::boolalpha;
+    std::cout << "x == y: " << (x == y) << "\n";   // true
+    std::cout << "x == z: " << (x == z) << "\n";   // false
+    std::cout << "p == q: " << (p == q) << "\n";   // true(Box<double> 自己的 operator==)
+    std::cout << x << "\n";                        // Box{1},ADL 找到 operator<<
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 barton.cpp -o barton && ./barton
+x == y: true
+x == z: false
+p == q: true
+Box{1}
+```
+
+`Box<int>` 和 `Box<double>` 各自有自己的 `operator==`,比较 `x == y` 走 `Box<int>` 的版本,比较 `p == q` 走 `Box<double>` 的版本。`std::cout << x` 之所以能工作,是因为 `operator<<` 是 `Box<int>` 的隐藏友元,ADL 通过实参 `x` 的类型发现了它。您既没写 `std::operator<<`,也没用 `using namespace`,全靠 ADL。
+
+## 隐藏友元的好处:不污染全局重载池
+
+隐藏友元的真正价值,在和「命名空间作用域的函数模板 operator==」对比时才看得清。老式写法是这样的:
+
+```cpp
+// 老式写法:在命名空间作用域定义一个 operator== 模板
+// (这里假设 Box 提供公开 value();本篇的 Box 把 v_ 设成私有,只能靠友元访问,
+//  所以老式写法要么 Box 开个公开接口,要么把这个 operator== 也声明成友元)
+template <typename T>
+bool operator==(const Box<T>& a, const Box<T>& b) {
+    return a.value() == b.value();
+}
+```
+
+这个 `operator==` 是一个**函数模板**,它活在命名空间作用域,对所有 `Box<T>` 的比较都参与候选。问题在于,它会参与**所有** `==` 表达式的重载解析(只要实参类型沾边),导致两个麻烦。一是编译慢,每次 `==` 编译器都要考虑这个模板能不能套上。二是二义性风险,如果别的命名空间也有 `operator==` 模板,两个模板可能同时匹配,产生 ambiguity。
+
+隐藏友元把这两个麻烦一起解决了。它不是函数模板,是随实例化生成的具体函数;它不在命名空间作用域可见,只有当 `==` 的实参类型精确匹配 `Box<T>` 时,ADL 才把它拉进候选。换句话说,它只在「该管的时候」出现,别的时候完全透明。这不仅让重载解析更快,也避免了不相关类型之间的意外匹配。
+
+::: warning 隐藏友元的「不跨界」是特性不是 bug
+
+隐藏友元只在实参类型精确匹配时被发现。`Box<int>` 的 `operator==` 只接受 `Box<int>`,不会接受 `Box<double>`。所以下面这行会编译报错:
+
+```cpp
+Box<int> x{1};
+Box<double> p{1.5};
+bool same = (x == p);   // 错:Box<int> 和 Box<double> 没有共同的 operator==
+```
+
+```text
+barton_bad.cpp:12:20: error: no match for 'operator=='
+      (operand types are 'Box<int>' and 'Box<double>')
+```
+
+这正是隐藏友元的安全性。如果您确实想让 `Box<int>` 和 `Box<double>` 能比较,您得显式写一个跨类型的运算符,而不是指望它「自动」发生。隐藏友元让类型关系变得明确,这正是它被推崇的原因。
+
+:::
+
+## 为什么这和 ADL 紧密相关
+
+隐藏友元离开 ADL 就没法用。前面说过,类内定义的友元不在命名空间作用域可见,普通查找找不到它。只有 ADL 才能发现它:调用 `x == y` 时,编译器通过实参 `x`(类型 `Box<int>`)的所在作用域,把 `Box<int>` 的隐藏友元 `operator==` 拉进候选集。
+
+所以隐藏友元是 ADL 的最佳搭档。ADL 让「定义在类里的运算符」能被找到,隐藏友元让「不该被找到的调用」找不到。两者配合,运算符的作用域被精确控制在「只对该类型生效」的范围。这也是上一篇花那么大篇幅讲 ADL 的原因,它是理解这一篇的前提。
+
+## 一个实战写法:给类型配齐比较运算符
+
+实际写库时,给一个类型配运算符的推荐模板长这样:
+
+```cpp
+class Temperature {
+    double kelvin_;
+public:
+    constexpr explicit Temperature(double k) : kelvin_(k) {}
+    constexpr double k() const { return kelvin_; }
+
+    // 隐藏友元:所有运算符都写成类内友元
+    friend constexpr bool operator==(Temperature a, Temperature b) {
+        return a.kelvin_ == b.kelvin_;
+    }
+    friend constexpr bool operator!=(Temperature a, Temperature b) {
+        return !(a == b);   // 复用 ==
+    }
+    friend constexpr bool operator<(Temperature a, Temperature b) {
+        return a.kelvin_ < b.kelvin_;
+    }
+    // ... 其它比较运算符
+};
+```
+
+C++20 之后有个更省事的办法:定义一个 `operator<=>`(三路比较运算符,本卷另一篇专门讲),编译器会自动帮您生成 `==`、`!=`、`<`、`<=`、`>`、`>=`。但如果您不用 spaceship,或者要自定义某些运算符的语义,隐藏友元仍然是首选写法。标准库里的迭代器、`std::chrono` 的时长类型,运算符基本都写成隐藏友元。
+
+下一篇咱们进别名模板和 using 声明。`template <typename T> using vec = std::vector<T>;` 这种写法怎么给类型起短名字、别名模板为什么不能特化、它在模板继承里引入基类名字的作用,都会讲到。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md b/documents/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md
new file mode 100644
index 000000000..7e9137229
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/08-alias-and-using.md
@@ -0,0 +1,175 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+description: C++11 的别名模板(template<typename T> using X = ...)解决了 typedef 不能参数化的老问题,C++14
+  起的 _t 别名和 C++17 起的 _v 变量让 type traits 写起来清爽,using 还能在模板继承里引入 dependent base 的名字。这一篇讲清这三种用法
+difficulty: intermediate
+order: 8
+platform: host
+prerequisites:
+- 名字查找与 ADL:两阶段查找是怎么回事
+- 类模板:成员、依赖名与惰性实例化
+reading_time_minutes: 7
+related:
+- 模板友元与 Barton-Nackman:隐藏友元技巧
+- CRTP:用奇递归模板做静态多态
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 类型别名
+- 泛型
+title: 别名模板与 using 声明:给类型起个短名字
+---
+# 别名模板与 using 声明:给类型起个短名字
+
+C++11 给类型起别名这件事做了一次大升级,引入了 `using` 的新用法和**别名模板**(alias template)。老式的 `typedef` 能给一个类型起别名,但它没法参数化,您想给 `std::vector<T>` 起个短名字,`typedef` 做不到,只能借类模板的嵌套类型绕一圈。`using` + 别名模板直接解决了这个问题。这一篇讲三种用法:别名模板本身、C++14 起 type traits 配的 `_t` 别名(C++17 又补了 `_v` 变量)、以及 `using` 在模板继承里引入基类名字的作用(承接第三篇讲过的 `this->`)。
+
+## typedef 的局限:不能参数化
+
+`typedef` 是 C 的老传统,能给一个类型起个新名字。
+
+```cpp
+typedef std::vector<int> IntVec;   // IntVec 就是 std::vector<int>
+IntVec v;
+```
+
+这没问题。但您想给「任意 `T` 的 `vector`」起个通用别名,`typedef` 就抓瞎了,它不能带模板参数。C++11 之前的绕路写法是借助类模板的嵌套 `using`:
+
+```cpp
+template <typename T>
+struct VecHelper {
+    using type = std::vector<T>;   // 嵌套在类模板里,才能参数化
+};
+
+VecHelper<int>::type v;   // 又是 ::type,啰嗦
+```
+
+这能跑,但每次用都要写 `VecHelper<int>::type`,前面讲依赖名时提过,这里还得加 `typename`,变成 `typename VecHelper<T>::type`,又长又别扭。
+
+## C++11 别名模板:using 的模板化
+
+C++11 的别名模板让这件事干净了。语法是 `template <...> using 名字 = ...`,直接给「带参数的类型」起别名:
+
+```cpp
+template <typename T>
+using Vec = std::vector<T>;   // 别名模板
+
+Vec<int> v = {1, 2, 3};        // 等价 std::vector<int>
+```
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 alias.cpp -o alias && ./alias
+size = 3
+```
+
+`Vec<int>` 就是 `std::vector<int>`,用起来没有任何区别。注意别名模板不是新类型,它纯粹是个「别名」,`Vec<int>` 和 `std::vector<int>` 是同一个类型,赋值、比较、重载都完全互通。这和 `typedef` 的语义一致,只是多了参数化能力。
+
+别名模板的好处不止是短。它还能表达一些 `typedef` 表达不了的复杂类型,比如函数指针类型、带分配器的容器,用 `using` 写出来比 `typedef` 清楚得多:
+
+```cpp
+// typedef 写函数指针类型,顺序绕得让人头疼
+typedef int (*Callback)(int, int);
+
+// using 写出来,左值右值一致,可读多了
+using Callback = int(*)(int, int);
+```
+
+现代 C++ 基本都用 `using` 替代 `typedef`,即使不带参数也用 `using`,风格统一。
+
+## C++14 的 `_t` 和 `_v`:type traits 的简写
+
+别名模板最实用的落地,是 C++14 给 `<type_traits>` 配的一套 `_t` 后缀别名。C++11 的 type traits 查询结果是嵌套在类里的 `::type` 或 `::value`,用起来啰嗦:
+
+```cpp
+// C++11:取去掉引用后的类型,得写 typename + ::type
+typename std::remove_reference<T>::type
+```
+
+C++14 给每个返回类型的 trait 加了一个 `_t` 别名模板,一行搞定:
+
+```cpp
+// C++14:别名模板,清爽
+std::remove_reference_t<T>
+```
+
+两者完全等价,`_t` 版本就是个别名模板,定义大致是 `template <typename T> using remove_reference_t = typename remove_reference<T>::type;`。返回布尔值的 trait 也有 `_v` 后缀的简写,比如 `std::is_integral<T>::value` 写成 `std::is_integral_v<T>`。这里要分清三样东西:`_t` 别名模板和 `_v` 变量模板都是**标准库助手**(`_t` 从 C++14 起,`_v` 从 C++17 起);而 `::value` 本身是 `std::integral_constant` 的静态成员常量,从 C++11 就有,跟变量模板是两码事。
+
+实测看两种写法的等价:
+
+```bash
+$ g++ -Wall -Wextra -std=c++17 alias.cpp -o alias && ./alias
+remove_reference_t<int&> is int?  true
+remove_reference<int&>::type is int? true
+```
+
+`_t` 让模板元编程代码的可读性提升了一个档次。vol3 讲 concepts 和元编程时您会看到,现代代码里 `::type` 几乎绝迹,全是 `_t`。这也是为什么本卷前面几篇的 type traits 例子我直接用 `_v` 后缀(`is_pointer_v`、`is_same_v`),它们都是变量模板(C++14/17)的简写,和 `_t` 别名模板是同一套思路。
+
+## 别名模板不能特化
+
+别名模板有个绕不过的限制:**它不能特化**,既不能全特化也不能偏特化。您想给某个具体类型提供一个特殊的别名实现,别名模板做不到。
+
+```cpp
+template <typename T>
+using V = T;
+
+// 试图特化别名模板 —— 编译报错
+template <>
+using V<int> = long;   // 错:别名模板不能特化
+```
+
+```text
+alias_bad.cpp:6:1: error: expected unqualified-id before 'using'
+```
+
+GCC 的报错措辞有点抽象,但意思就是「别名模板不接受特化」。如果您确实需要「针对不同类型给不同的类型别名」,得用类模板包一层(类模板能特化),把别名藏在嵌套 `using` 里,再写它的特化版本。这是别名模板相比类模板的一个能力短板,设计上就是这么定的,别名模板定位是「纯转发」,不做类型计算的分发。
+
+## using 在模板继承里:引入 dependent base 的名字
+
+第三篇讲 dependent base 时说过,访问基类模板的成员要用 `this->`,因为编译器在第一阶段不查 dependent base。`using` 提供了另一种写法:**用 `using` 声明把基类的名字引入派生类作用域**,之后调用就不用每次写 `this->`。
+
+```cpp
+#include <iostream>
+
+template <typename T>
+struct Base {
+    static T kDefault;
+    void greet() { std::cout << "Base::greet\n"; }
+};
+template <typename T>
+T Base<T>::kDefault{42};
+
+template <typename T>
+struct Derived : Base<T> {
+    // using 把 Base<T>::kDefault 和 Base<T>::greet 引入 Derived 作用域
+    using Base<T>::kDefault;
+    using Base<T>::greet;
+
+    T fetch() const { return kDefault; }   // 直接用,不用 this->
+    void hello() { greet(); }              // 直接用,不用 this->
+};
+```
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 using_base.cpp -o using_base && ./using_base
+fetch = 42
+Base::greet
+```
+
+`using Base<T>::kDefault` 告诉编译器「`kDefault` 这个名字指的是 `Base<T>` 里的那个」,把查找绑定好,后续 `fetch` 里写 `kDefault` 就能直接找到,不用 `this->`。
+
+`using` 引入和 `this->` 是解决同一个问题的两种写法,选哪个看场景。如果只是偶尔访问一两个基类成员,`this->` 现写现用更轻便。如果要频繁访问多个基类成员(比如派生类里到处用基类的类型别名和函数),在类开头集中写一组 `using` 声明,代码更干净。两种都是合法的现代写法,`using` 还有个额外好处:它能把基类的类型别名(`value_type`、`iterator` 这种)「继承」下来,让派生类对外暴露统一的类型接口,STL 容器的适配器和派生类大量这么用。
+
+## 别名模板和模板参数推导
+
+最后提一个 C++14 之后的发展。别名模板能参与模板参数推导,这让代码更灵活。比如您有个函数接受 `std::vector<T>`,传一个 `Vec<int>`(别名)进去,推导照常工作,因为别名就是原类型。C++20 的 CTAD(类模板参数推导)和别名模板也有交互,允许从构造函数推导别名模板的参数,这个比较深,vol3 讲 concepts 和推导时会专门讲。这一篇您只要记住:别名模板是「透明的」,它在推导、重载、类型等价上都和它指向的原类型完全一致。
+
+下一篇是本卷概念部分的重头戏:CRTP,奇递归模板模式。它用「派生类把自己作为模板参数传给基类」的奇巧结构,做出编译期的静态多态,避开虚函数的运行时开销,是 Eigen、表达式模板等高性能库的核心技术。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md b/documents/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
new file mode 100644
index 000000000..4902abac8
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/09-crtp.md
@@ -0,0 +1,220 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+- 23
+description: CRTP 让派生类把自己作为模板参数传给基类,做出编译期的静态多态,避开虚函数的 vtable 和运行时分派。这一篇讲清它的结构、零开销的汇编证据、mixin
+  等典型用途,以及它的坑和 C++23 deducing this 这个现代替代
+difficulty: intermediate
+order: 9
+platform: host
+prerequisites:
+- 类模板:成员、依赖名与惰性实例化
+- 名字查找与 ADL:两阶段查找是怎么回事
+- 别名模板与 using 声明:给类型起个短名字
+reading_time_minutes: 9
+related:
+- 综合项目:fixed_vector<T, N>
+- 模板友元与 Barton-Nackman:隐藏友元技巧
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- CRTP
+- 泛型
+- 零开销抽象
+title: CRTP:用奇递归模板做静态多态
+---
+# CRTP:用奇递归模板做静态多态
+
+CRTP,全称 Curiously Recurring Template Pattern,奇递归模板模式。它的结构乍一看很怪:派生类在继承基类时,把自己作为模板参数传给基类。`struct Derived : Base<Derived>`。这种「自己引用自己」的奇巧写法,能做出编译期的**静态多态**,在不需要运行时确定具体类型时,完全避开虚函数的 vtable 和分派开销。Eigen 的表达式模板、很多高性能库的 mixin 机制,都建立在 CRTP 上。这一篇讲清它的结构、零开销的汇编证据、几个典型用途,以及它绕不开的坑。
+
+## CRTP 长什么样:派生类把自己传给基类
+
+先看最小例子。基类 `Shape` 是个模板,模板参数是「派生类自己」。
+
+```cpp
+#include <iostream>
+
+template <typename Derived>
+struct Shape {
+    const char* name() {
+        return static_cast<Derived*>(this)->name_impl();   // 把 this 转成派生类指针
+    }
+    double area() {
+        return static_cast<Derived*>(this)->area_impl();
+    }
+};
+
+struct Circle : Shape<Circle> {        // Circle 把自己 Circle 传给 Shape
+    double r;
+    explicit Circle(double r_) : r(r_) {}
+    const char* name_impl() { return "Circle"; }
+    double area_impl() { return 3.14159 * r * r; }
+};
+
+struct Square : Shape<Square> {
+    double side;
+    explicit Square(double s) : side(s) {}
+    const char* name_impl() { return "Square"; }
+    double area_impl() { return side * side; }
+};
+```
+
+关键在 `struct Circle : Shape<Circle>` 这一行。`Circle` 继承 `Shape`,但传给 `Shape` 的模板参数是 `Circle` 自己。于是基类 `Shape<Derived>` 里的 `Derived` 就是 `Circle`,基类的 `area()` 通过 `static_cast<Derived*>(this)->area_impl()` 调用,实际调的是 `Circle::area_impl`。
+
+跑一下:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 crtp_basic.cpp -o crtp_basic && ./crtp_basic
+Circle area = 12.5664
+Square area = 9
+```
+
+`Circle` 走 `Circle::area_impl`,`Square` 走 `Square::area_impl`,各算各的。看起来和虚函数多态效果一样,但机制完全不同。
+
+## 静态多态:编译期就知道具体类型
+
+虚函数的多态是**运行时**的。`base->area()` 时,`base` 指向的具体类型要到运行时才知道,编译器只能生成「查 vtable、间接调用」的代码。
+
+CRTP 的多态是**编译期**的。`Shape<Circle>::area()` 在实例化时,`Derived` 已经钉死是 `Circle`,`static_cast<Derived*>(this)->area_impl()` 就是 `static_cast<Circle*>(this)->area_impl()`,编译器清楚地知道调的是 `Circle::area_impl`,可以直接调用,甚至内联。没有 vtable,没有运行时分派。
+
+这一点是 CRTP 的核心价值:**在编译期能确定具体类型时,用静态多态替代虚函数,换来零开销**。
+
+## 零开销的汇编证据
+
+口说无凭,看汇编。写一个 CRTP 版和一个虚函数版,功能一样(返回 42),用 `-O2` 编译,对比 `use` 函数的反汇编。
+
+```cpp
+// crtp_asm.cpp —— CRTP 版
+template <typename D>
+struct Base {
+    int compute() { return static_cast<D*>(this)->compute_impl(); }
+};
+struct Concrete : Base<Concrete> {
+    int compute_impl() { return 42; }
+};
+int use_crtp() { Concrete c; return c.compute(); }
+```
+
+CRTP 版 `use_crtp` 的完整反汇编只有两条指令:
+
+```text
+0000000000000000 <_Z8use_crtpv>:
+   0:   b8 2a 00 00 00   mov    $0x2a,%eax    ; 0x2a = 42,直接把结果放进返回值
+   5:   c3               ret
+```
+
+`compute()` 和 `compute_impl()` 全被内联了,编译器直接算出结果是 42,连函数调用都省了。`use_crtp` 就是「把 42 放进 eax,返回」。
+
+再看虚函数版(通过引用调用,强制虚分派):
+
+```cpp
+// vtable_asm.cpp —— 虚函数版
+struct Base {
+    virtual int compute() = 0;
+    virtual ~Base() = default;
+};
+struct Concrete : Base {
+    int compute() override { return 42; }
+};
+int use_virtual(Base& b) { return b.compute(); }   // 通过引用,编译器无法去虚化
+```
+
+`use_virtual` 的反汇编要长得多:
+
+```text
+0000000000000000 <_Z11use_virtualR4Base>:
+   0:   48 8b 07         mov    (%rdi),%rax        ; 从对象取 vtable 指针
+   3:   48 8d 15 ...     lea    ...(%rip),%rdx     ; Concrete 的 vtable 地址
+   a:   48 8b 00         mov    (%rax),%rax        ; 从 vtable 取 compute 的函数指针
+   d:   48 39 d0         cmp    %rdx,%rax          ; 推测去虚化:是不是 Concrete?
+  10:   75 0e            jne    20                 ; 不是才走间接 call
+  12:   b8 2a 00 00 00   mov    $0x2a,%eax         ; 是 Concrete,直接返回 42
+  17:   c3               ret
+```
+
+虚函数版有 vtable 指针的两次解引用(`mov (%rdi)` 取 vtable,`mov (%rax)` 取函数指针),还有一次比较和条件跳转(GCC 的「推测去虚化」优化:先猜 `b` 是不是 `Concrete`,猜中就直接返回,猜不中才走真正的间接调用)。即便开了 `-O2`,这套 vtable 访问和去虚化检查的开销仍在。
+
+对比一目了然:CRTP 版两条指令、零内存访问;虚函数版七条指令、两次内存访问(vtable)。这就是「静态多态零开销」最直接的证据。在 Eigen 这种数值计算库里,表达式求值被 CRTP 完全摊平到编译期,运行时就是一串直接的算术指令,没有任何多态分派,这是它能和手写循环一样快的根本原因。
+
+## CRTP 的典型用途
+
+CRTP 不只用来做静态多态,它还有几个高频用法。
+
+**静态多态**(本篇重点)。基类定义接口骨架,派生类提供具体实现,编译期绑定,无虚函数开销。适合「接口固定、实现多样、性能敏感」的场景,比如数值库的运算、容器的迭代器。
+
+**Mixin(混入)**。基类给派生类「注入」一段通用功能,派生类只需提供基础数据。比如给所有支持 `<` 的类型自动生成全套比较运算符:
+
+```cpp
+template <typename Derived>
+struct Comparable {
+    friend bool operator>(const Derived& a, const Derived& b)  { return b < a; }
+    friend bool operator<=(const Derived& a, const Derived& b) { return !(b < a); }
+    friend bool operator>=(const Derived& a, const Derived& b) { return !(a < b); }
+    friend bool operator!=(const Derived& a, const Derived& b) { return !(a == b); }
+};
+
+struct Point : Comparable<Point> {
+    int x, y;
+    Point(int x_, int y_) : x(x_), y(y_) {}
+    friend bool operator<(const Point& a, const Point& b) { return a.x < b.x; }
+    friend bool operator==(const Point& a, const Point& b) { return a.x == b.x; }
+};
+// Point 现在自动有了 > <= >= !=,只需实现 < 和 ==
+```
+
+跑一下,确认 mixin 注入的运算符确实能用:
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 comparable.cpp -o comparable && ./comparable
+p1 < p2:  true
+p1 > p2:  false
+p1 <= p2: true
+p1 >= p2: false
+p1 != p2: true
+```
+
+`Point` 只写了 `<` 和 `==`,其余四个比较运算符全由 `Comparable<Point>` 自动补齐。
+
+只要 `Point` 实现了 `<` 和 `==`,混入 `Comparable<Point>` 就把其余比较运算符全自动补齐了。这和第三部分要讲的 Barton-Nackman 是一对搭档,CRTP 提供结构,友元注入提供运算符。
+
+**编译期接口注入 / 策略注入**。基类可以要求派生类提供某些 typedef 或常量,在编译期检查,实现「静态接口」。比如基类里写 `using value_type = typename Derived::value_type;`,派生类没暴露 `value_type` 就编不过。这种「concept-like」的编译期约束,在 concepts 出现之前常用 CRTP 模拟。
+
+**表达式模板**(expression templates)。Eigen 的 `a + b * c` 不产生临时矩阵,而是生成一个「表达式类型」记录运算,最后赋值时一次性求值,避免中间临时对象。这套机制完全建立在 CRTP 上,是 CRTP 最惊艳的应用,vol3 元编程会专门拆。
+
+## CRTP 的坑
+
+CRTP 强大,但有几个坑要避。
+
+**基类构造时派生类未完成**。基类的构造函数执行时,派生类部分还没构造,这时如果在基类构造函数里调 `static_cast<Derived*>(this)` 去访问派生类成员,是未定义行为(对象还没成形)。同理基类析构函数里也别调派生类方法。CRTP 的跨层调用只在那次调用时对象已经完整的情况下安全,构造/析构期间不行。
+
+**`static_cast` 的安全假设**。`static_cast<Derived*>(this)` 假设 `this` 确实指向一个 `Derived` 对象,这个假设由您(写 `struct Derived : Base<Derived>` 时)保证。好消息是类型系统其实帮您拦了一部分:如果您写歪了,比如 `struct Wrong : Base<Other>`(`Wrong` 和 `Other` 毫无关系),基类里的 `static_cast<Other*>(this)` 通常会编译失败,因为 `Wrong*` 和 `Other*` 是无关类型,`static_cast` 拒绝转换。所以 CRTP 的类型安全比看上去强,前提是您老老实实把派生类自己传给基类。
+
+**虚函数和 CRTP 不互通**。CRTP 的 `area()` 不是虚函数,您没法把 `Circle*` 和 `Square*` 塞进同一个 `Shape*` 数组里统一调用 `area()`。需要运行时异构集合的场景,还得用虚函数。CRTP 适合「编译期就知道具体类型」的场景,这是它的边界。
+
+## C++23 deducing this:CRTP 的现代替代
+
+CRTP 写起来有点绕(`static_cast<Derived*>(this)`),C++23 给了一个更直观的替代,叫 **deducing this**(显式对象参数)。它让成员函数显式接收一个 `this` 参数,编译器根据调用对象的类型推导:
+
+```cpp
+// C++23 deducing this 写法:Shape 不再是模板
+struct Shape {
+    // self 的类型由调用对象推导,不再是硬编码的 Derived
+    double area(this auto const& self) { return self.area_impl(); }
+};
+
+struct Circle : Shape {   // Circle 仍继承 Shape,但不用再把 Shape<Circle> 这样传模板参数
+    double r;
+    double area_impl() const { return 3.14159 * r * r; }
+};
+// Circle c; c.area() 里 self 推导为 Circle const&,调 Circle::area_impl
+```
+
+deducing this 让静态多态写得更像普通函数,不用 `static_cast`、不用把派生类传给自己。它是 C++23 的重要特性,本卷第三部分(元编程)和 vol2 讲现代特性时会详讲。在那之前,CRTP 仍是 C++17 及更早项目里做静态多态的标准手段,您读 Eigen、读 Boost 的代码,到处都是它。
+
+下一篇是本卷概念部分的收尾:一个 `fixed_vector<T, N>` 综合项目。它用编译期固定大小的连续存储,把前面学的模板、非类型参数、迭代器、CRTP(可选)全串起来,实现一个零动态分配的定长容器,并和 C++23/26 的 `std::inplace_vector` 对比。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md b/documents/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md
new file mode 100644
index 000000000..a3642f062
--- /dev/null
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/10-fixed-vector.md
@@ -0,0 +1,187 @@
+---
+chapter: 12
+cpp_standard:
+- 11
+- 14
+- 17
+- 20
+- 26
+description: 把本卷前 9 篇学的全串起来,实现一个编译期定长、连续存储、零动态分配的 vector。完整代码 + 实测,再和 C++26 的 std::inplace_vector
+  以及 EASTL/Boost/Folly 的同类实现对比
+difficulty: intermediate
+order: 10
+platform: host
+prerequisites:
+- CRTP:用奇递归模板做静态多态
+- 非类型模板参数:从整数到 C++20 的浮点与类类型
+- 类模板:成员、依赖名与惰性实例化
+reading_time_minutes: 9
+related:
+- 模板导论:从一份代码配方说起
+tags:
+- host
+- cpp-modern
+- intermediate
+- 模板
+- 容器
+- vector
+- 零开销抽象
+title: 综合项目:fixed_vector<T, N>
+---
+# 综合项目:fixed_vector&lt;T, N&gt;
+
+走到这里,本卷前 9 篇的概念该一起练手了。咱们实现一个 `fixed_vector<T, N>`:一个编译期固定容量、连续存储、**零动态分配**的 vector。它综合用到类模板、非类型模板参数、迭代器,如果您愿意还能用 CRTP 给迭代器加接口。这个练习不是空想,标准库的 `std::inplace_vector`(C++26)就是它的「官方版」,工业界早有 EASTL 的 `fixed_vector`、Boost 的 `static_vector`、Folly 的 `small_vector` 在用同一套思路。咱们写一个教学简化版,讲清每一块设计,最后和标准库对照。
+
+## 目标:一个什么样的容器
+
+先定清楚 `fixed_vector` 要满足什么。
+
+第一,容量 `N` 在编译期固定,作为非类型模板参数。第二,元素连续存储,能用 `operator[]` 随机访问,裸指针能当迭代器用。第三,**不分配堆内存**,所有元素放在对象自身的存储里,这在嵌入式、实时系统、禁止异常分配的环境里特别有用。第四,元素数可以动态变化(从 0 到 N),这点和「编译期就构造所有元素」的 `std::array` 不同,`fixed_vector` 是按需构造。
+
+这套目标和 `std::inplace_vector` 完全一致。cppreference 对 `inplace_vector` 的定义就是「a dynamically-resizable array with contiguous inplace storage」,容量编译期固定等于 N,元素存在对象自身内。咱们的 `fixed_vector` 是它的教学缩影。
+
+## 实现骨架
+
+模板签名是 `template <typename T, std::size_t N>`,一个类型参数加一个非类型参数。存储用 `std::array<T, N>` 当后端,省得自己管对齐和原始内存;再用一个 `size_` 记录当前实际元素数。
+
+```cpp
+#include <array>
+#include <cstddef>
+#include <stdexcept>
+
+template <typename T, std::size_t N>
+class FixedVector {
+    std::array<T, N> data_{};   // 定长存储,栈上,无堆分配
+    std::size_t size_ = 0;
+public:
+    static constexpr std::size_t capacity_v = N;
+    // ... 成员函数
+};
+```
+
+`data_` 是 `std::array<T, N>`,它本身就是连续存储,`size_` 跟踪当前塞了多少元素。`capacity_v` 是一个静态常量,对外暴露容量,这正是非类型参数 `N` 的典型用法。
+
+## push_back 与边界处理
+
+`push_back` 在尾部加一个元素。关键边界是容量耗尽:超过 `N` 时怎么办。标准库的 `inplace_vector` 在这种情况抛 `std::bad_alloc`(注意是 `bad_alloc`,不是 `out_of_range`,这是 `inplace_vector` 的规定)。咱们的教学版图省事抛 `std::out_of_range`,语义清楚就行。
+
+```cpp
+constexpr void push_back(const T& value) {
+    if (size_ >= N) {
+        throw std::out_of_range("FixedVector full");
+    }
+    data_[size_++] = value;
+}
+```
+
+注意整个函数标了 `constexpr`,在 C++20 里这意味着 `push_back` 能在编译期执行(只要 `T` 的操作都是常量表达式)。`fixed_vector` 全套成员都能做成 `constexpr`,这是它和 `std::array` 一样适合编译期计算的好处。
+
+## 元素访问与迭代器
+
+`operator[]` 直接转发给底层 `std::array`,不做边界检查(和 `std::vector::operator[]` 一致,要检查用 `at()`)。
+
+```cpp
+constexpr T& operator[](std::size_t i) { return data_[i]; }
+constexpr const T& operator[](std::size_t i) const { return data_[i]; }
+constexpr std::size_t size() const { return size_; }
+```
+
+迭代器是这份实现里最优雅的部分。因为元素连续存储,裸指针 `T*` 天生就是一个满足随机访问迭代器要求的类型(支持 `*`、`++`、`+n`、比较)。所以 `begin()` 和 `end()` 直接返回指针,不用自己定义迭代器类。
+
+```cpp
+constexpr T* begin() { return data_.data(); }
+constexpr T* end() { return data_.data() + size_; }
+constexpr const T* begin() const { return data_.data(); }
+constexpr const T* end() const { return data_.data() + size_; }
+```
+
+`data_.data()` 返回底层数组的首元素指针,`end()` 指向「当前最后一个元素的下一个」。有了这组 `begin/end`,范围 for 循环、`std::sort`、`std::find` 这些标准算法都能直接用在 `fixed_vector` 上,因为它们要的只是迭代器接口,而裸指针正好满足。这是 STL「迭代器统一容器和算法」设计哲学的直接体现。
+
+## 完整代码与实测
+
+把上面的拼起来,加个 `main` 跑一遍。
+
+```cpp
+#include <array>
+#include <cstddef>
+#include <iostream>
+#include <stdexcept>
+
+template <typename T, std::size_t N>
+class FixedVector {
+    std::array<T, N> data_{};
+    std::size_t size_ = 0;
+public:
+    static constexpr std::size_t capacity_v = N;
+
+    constexpr void push_back(const T& value) {
+        if (size_ >= N) throw std::out_of_range("FixedVector full");
+        data_[size_++] = value;
+    }
+    constexpr T& operator[](std::size_t i) { return data_[i]; }
+    constexpr const T& operator[](std::size_t i) const { return data_[i]; }
+    constexpr std::size_t size() const { return size_; }
+
+    constexpr T* begin() { return data_.data(); }
+    constexpr T* end() { return data_.data() + size_; }
+    constexpr const T* begin() const { return data_.data(); }
+    constexpr const T* end() const { return data_.data() + size_; }
+};
+
+int main() {
+    FixedVector<int, 8> v;
+    for (int i = 1; i <= 5; ++i) v.push_back(i * 10);
+
+    std::cout << "size = " << v.size() << " capacity = " << decltype(v)::capacity_v << "\n";
+    std::cout << "elements: ";
+    for (auto x : v) std::cout << x << " ";
+    std::cout << "\n";
+    std::cout << "v[2] = " << v[2] << "\n";
+    std::cout << "sizeof(FixedVector<int,8>) = " << sizeof(FixedVector<int, 8>) << "\n";
+    std::cout << "sizeof(int*) = " << sizeof(int*) << " (对比:动态 vector 至少含 3 个指针)\n";
+    return 0;
+}
+```
+
+```bash
+$ g++ -Wall -Wextra -std=c++20 fixed_vector.cpp -o fixed_vector && ./fixed_vector
+size = 5 capacity = 8
+elements: 10 20 30 40 50
+v[2] = 30
+sizeof(FixedVector<int,8>) = 40
+sizeof(int*) = 8 (对比:动态 vector 至少含 3 个指针)
+```
+
+几条关键结果对一下。`size = 5 capacity = 8`:塞了 5 个,容量 8。范围 for 遍历输出 `10 20 30 40 50`,说明裸指针迭代器工作正常。`v[2] = 30`,`operator[]` 随机访问没问题。最有说服力的是 `sizeof(FixedVector<int,8>) = 40`:8 个 `int` 占 32 字节,加上 `size_` 的 8 字节,正好 40,里面**没有任何堆指针**。对比之下,`std::vector` 至少含三个指针(数据指针、容量、大小),外加一次堆分配。
+
+## 零动态分配,为什么重要
+
+`sizeof` 没有堆指针,意味着 `fixed_vector` 的所有存储都在对象自身里。这带来几个实际好处。
+
+性能可预测。没有堆分配,就没有分配器的开销和内存碎片,构造析构是确定的。在实时系统、游戏引擎的热点路径上,一次 `std::vector` 的堆分配可能就是几微秒的抖动,`fixed_vector` 完全没有。
+
+异常安全边界清晰。`fixed_vector` 只在容量耗尽时抛异常(`push_back` 到 N 上限),不像 `std::vector` 扩容时可能因为分配失败抛 `bad_alloc`。在禁用异常或禁用堆的环境(很多嵌入式项目)里,`fixed_vector` 能用,`std::vector` 不能。
+
+缓存友好。元素连续存储且在对象自身内,访问模式对 CPU 缓存非常友好,这点和 `std::array`、`std::vector` 一样。
+
+## 和 std::inplace_vector(C++26)对比
+
+`std::inplace_vector` 是这套思路的标准库版本,特性测试宏 `__cpp_lib_inplace_vector`(现行值 `202603L`),对应 **C++26**(早期提案瞄准过 C++23,最终落定 C++26)。它的设计和咱们的 `fixed_vector` 高度一致:编译期固定容量、连续存储、无堆分配、按需构造元素。
+
+标准库版本比咱们的教学版完整得多。它有一整套成员函数:`emplace_back`、`try_push_back`(满了不抛异常,返回空的 `std::optional<reference>`)、`unchecked_push_back`(不检查,调用者自己保证没满,用于性能关键路径)、`insert`、`erase`、`resize` 等等。满了之后的策略也更细致:`push_back` 满了抛 `std::bad_alloc`,`try_push_back` 满了返回空 optional,`unchecked_push_back` 假定没满直接塞。这套「抛异常 / try / unchecked」三档 API,是工业级容器设计的成熟范式。
+
+工业界在这之前早有同类实现。EASTL(EA 的 STL 替代)有 `fixed_vector`,Boost.Container 有 `static_vector`,Folly(Facebook)有 `small_vector`(带 small buffer 优化)。它们各有侧重,但核心都是「连续存储 + 编译期或半编译期容量 + 避免堆分配」。咱们的 `FixedVector` 把最核心的骨架抽出来讲明白,理解了它,再去读这些工业实现就轻松了。
+
+## 可以接着扩展的方向
+
+这个教学版还差几块,留作您练手的方向。
+
+加 `try_push_back` 和 `unchecked_push_back`,对标 `inplace_vector` 的三档 API。`try_push_back` 返回 `std::optional<reference>`,满了返回空 optional(不抛异常);`unchecked_push_back` 假定没满,省掉检查。
+
+用对齐的原始内存替代 `std::array`,实现「按需构造」。现在 `std::array<T, N>` 会默认构造所有 N 个元素,哪怕您只用 3 个;真正的 `inplace_vector` 用 `alignas(T)` 的原始字节数组,只在 `push_back` 时 placement new 构造元素,省掉无用构造。这块涉及 std::optional、placement new、手动析构,是更接近标准库实现的练手。
+
+给迭代器加 CRTP 接口。如果您想让 `fixed_vector` 的迭代器支持一些自定义行为(比如调试模式下的边界检查),可以用 CRTP 写一个迭代器基类。这会把本卷第 9 篇的 CRTP 和这里的迭代器结合起来。
+
+---
+
+走到这里,本卷第一部分「模板基础(C++11-14)」就完整了。从一份代码配方讲起,经过函数模板的编译模型、类模板的惰性实例化、特化与偏特化的模式匹配、非类型参数、两阶段名字查找与 ADL、隐藏友元和 Barton-Nackman、别名模板、CRTP 静态多态,最后用 `fixed_vector` 把它们全焊在一起。第二部分(现代模板技术,C++17)会接着讲类型萃取、SFINAE、`if constexpr`、变参模板、折叠表达式、完美转发,把元编程的工具箱补齐;第三部分(C++20-23)再上 concepts、requires 和反射,把 TMP 从黑魔法变成人能写的代码。模板这条路,咱们才刚上道。
diff --git a/documents/vol4-advanced/vol1-basics-cpp11-14/index.md b/documents/vol4-advanced/vol1-basics-cpp11-14/index.md
index 5b9117751..ff175c3d8 100644
--- a/documents/vol4-advanced/vol1-basics-cpp11-14/index.md
+++ b/documents/vol4-advanced/vol1-basics-cpp11-14/index.md
@@ -1,23 +1,25 @@
 ---
 title: "模板基础（C++11-14）"
-description: "C++模板编程的核心基础：从函数模板到 CRTP 的完整入门"
+description: "C++ 模板编程的核心基础:从函数模板到 CRTP 的完整入门"
 ---
 
 # 模板基础（C++11-14）
 
-> 状态：待编写
+C++ 模板是泛型编程的核心机制。本部分从「会用模板」推进到「想写库、读得懂 STL 源码」的视角,讲透模板的编译模型、特化与偏特化、非类型参数、两阶段名字查找、隐藏友元、别名模板和 CRTP,最后用一个 `fixed_vector<T, N>` 综合项目把前九篇焊在一起。
 
-C++ 模板是泛型编程的核心机制。本部分从零开始建立完整的模板基础知识体系，覆盖函数模板、类模板、特化与偏特化、非类型参数、名称查找、友元注入、别名、继承与 CRTP。
+每篇都带「上手跑一跑」的真实编译输出,该踩的坑写成 `::: warning` 预警块,关键的编译期行为用汇编佐证。
 
-## 本章内容（待编写）
+配套可运行示例在 [code/examples/vol4/vol1-basics-cpp11-14/](https://github.com/Awesome-Embedded-Learning-Studio/Tutorial_AwesomeModernCPP/tree/main/code/examples/vol4/vol1-basics-cpp11-14),四个最有复用价值的例子(fixed_vector、CRTP 静态多态、Comparable mixin、手写 type_traits),每个文件 `g++ -std=c++20 xxx.cpp` 直接跑。
 
-1. 模板导论
-2. 函数模板
-3. 类模板
-4. 模板特化与偏特化
-5. 非类型模板参数
-6. 模板参数依赖与名字查找
-7. 模板友元与 Barton-Nackman
-8. 模板别名与 Using 声明
-9. 模板与继承（CRTP）
-10. 综合项目：fixed_vector&lt;T, N&gt;
+<ChapterNav variant="sub">
+  <ChapterLink href="01-templates-introduction">模板导论:从一份代码配方说起</ChapterLink>
+  <ChapterLink href="02-function-templates-deep">函数模板深化:编译模型与那个不能偏特化的坑</ChapterLink>
+  <ChapterLink href="03-class-templates">类模板:成员、依赖名与惰性实例化</ChapterLink>
+  <ChapterLink href="04-specialization-partial">模板特化与偏特化:模式匹配的艺术</ChapterLink>
+  <ChapterLink href="05-non-type-parameters">非类型模板参数:从整数到 C++20 的浮点与类类型</ChapterLink>
+  <ChapterLink href="06-name-lookup-and-adl">名字查找与 ADL:两阶段查找是怎么回事</ChapterLink>
+  <ChapterLink href="07-friends-and-barton-nackman">模板友元与 Barton-Nackman:隐藏友元技巧</ChapterLink>
+  <ChapterLink href="08-alias-and-using">别名模板与 using 声明:给类型起个短名字</ChapterLink>
+  <ChapterLink href="09-crtp">CRTP:用奇递归模板做静态多态</ChapterLink>
+  <ChapterLink href="10-fixed-vector">综合项目:fixed_vector</ChapterLink>
+</ChapterNav>