1. 项目概述：为什么现代C++内存管理依然值得深挖？

如果你写过几年C++，尤其是经历过从C++98/03到C++11/14/17乃至现在C++20/23的变迁，可能会觉得“内存管理”这个话题是老生常谈了。智能指针不是已经解决了一切吗？std::unique_ptr和std::shared_ptr一用，new/delete似乎就可以丢进历史的垃圾桶了。但现实情况是，在高性能计算、游戏引擎、嵌入式系统、高频交易这些领域，内存管理的细微差别直接决定了程序的吞吐量、延迟和稳定性。智能指针是安全网，但绝不是性能的“免死金牌”。不当的使用，比如无意识的std::shared_ptr拷贝、在关键循环中频繁分配小对象，依然会让你的程序性能“断崖式”下跌。

我最近在为一个实时数据处理模块做性能剖析时，就发现一个看似无害的日志函数，因为内部使用了std::string来格式化消息（导致堆分配），在高压下成了最大的性能瓶颈，其开销甚至超过了核心业务逻辑。这让我意识到，现代C++给了我们更安全的工具，但并没有消除对内存管理“技艺”的需求。相反，它要求我们从“避免错误”的层面，上升到“追求极致效率”的层面。

今天要聊的这五种技巧，不是教你背八股文，也不是重复教科书上的RAII。它们是我在多年踩坑和优化实践中总结出来的，介于“基础语法”和“复杂系统设计”之间的实战经验。目标是让你在已经使用了现代C++特性（如智能指针、容器）的基础上，进一步榨干内存系统的潜力，写出既安全又高效的代码。无论你是正在为面试准备C++内存相关的难题，还是在为手头的项目寻找性能提升点，这些内容都应该能给你带来直接的启发。

2. 核心思路：从“被动安全”到“主动掌控”的转变

传统的C++内存管理教学，核心是“避免泄漏和悬垂指针”，解决方案是RAII和智能指针。这解决了“正确性”问题，我们可以称之为“被动安全”——只要遵循规则，就能很大程度上避免灾难。然而，对于性能敏感的场景，我们需要的是“主动掌控”。这意味着我们需要深入理解内存分配器的行为、对象生命周期的模式，并主动设计内存的获取和释放策略，以减少延迟、提高局部性、降低碎片。

现代C++的内存优化技巧，大体遵循以下几个核心思路，这也是我们后续五种技巧的分类依据：

2.1 减少动态分配的频率和开销动态内存分配（new/malloc）是昂贵的操作，它可能涉及系统调用、锁竞争（在多线程环境下）和遍历空闲链表。第一个优化方向就是想方设法减少它的发生。比如，能用栈就别用堆，能复用就别重新分配。

2.2 改善内存访问的局部性CPU缓存的速度远高于主存。如果程序访问的数据在内存中是连续存放的，缓存命中率会大幅提升，性能差异可能达到数量级。优化数据结构和访问模式，让一起用的数据挨在一起，是第二个关键思路。

2.3 精细化控制对象生命周期和内存布局知道对象何时生、何时死，才能做出最优的分配决策。同时，控制对象在内存中的精确排列（比如避免因为字节对齐产生的“空洞”），可以节省内存，并进一步提升局部性。

2.4 利用现代C++语言特性替代手动管理std::unique_ptr不仅安全，其默认的删除器是delete，无额外开销。std::make_shared在分配控制块时可以和对象本身一起分配，减少一次分配次数。这些现代特性用对了，本身就是一种优化。

2.5 针对特定场景使用定制化分配策略通用分配器（malloc/new）为了应对所有情况，必然要做很多权衡。如果你的程序有特定的内存使用模式（比如大量固定大小的小对象、短寿命的临时对象），自定义分配器（如内存池）可以带来巨大的性能提升。

基于这五个思路，我们展开五种具体的、可立即上手的优化技巧。

3. 技巧一：拥抱“栈”与“小对象优化”，将动态分配扼杀在摇篮里

这是最直接、也往往最有效的优化。许多不必要的堆分配，源于开发者对“栈”的能力认识不足，或者对标准库容器的实现细节不了解。

3.1 优先使用栈内存和值语义对于生命周期局限于某个作用域（如函数内）、且尺寸不大的对象，坚决使用栈分配。这包括基本类型、小型结构体（struct）、以及在函数内部创建的临时对象。

// 反面例子：不必要的堆分配 void processData() { std::vector<int>* data = new std::vector<int>(1000); // ... 使用 data delete data; // 容易忘记，且分配开销大 } // 正面例子：使用栈上的自动对象（RAII） void processData() { std::vector<int> data(1000); // 容器本身在栈上，其内部缓冲区在堆上 // ... 使用 data } // 自动析构，安全无泄漏

但更重要的是，对于容器内的元素，也要考虑值语义。如果元素类型很小（比如int,double, 小型POD结构体），直接存储其值，而不是存储指针。存储指针意味着每个元素额外一次堆分配，并且访问时多一次解引用，破坏局部性。

// 存储值（推荐用于小型对象） std::vector<Point> points; // Point 是 {double x, y;} // 存储指针（不推荐，除非有共享、多态等需求） std::vector<Point*> points; // 每个Point都需要单独new，灾难！

3.2 理解并利用“小对象优化”许多标准库容器和智能指针为了性能，实现了“小对象优化”（Small Object Optimization, SOO）或“短字符串优化”（Short String Optimization, SSO）。以std::string为例，许多实现（如GCC的libstdc++, Clang的libc++）会在字符串较短时（例如15或22个字符以内），直接将字符数据存储在string对象自身的栈内存中，而不是去堆上分配。这意味着创建、拷贝、销毁短字符串的成本极低，几乎和栈上字符数组一样。

std::string shortStr = “Hello”; // 很可能没有堆分配 std::string longStr = “This is a very long string that definitely exceeds the SSO buffer size”; // 触发堆分配

std::function、std::optional等也可能有类似的优化。实操心得：在性能关键路径上，如果可能，尽量将数据规模控制在SOO的范围内。例如，传递短字符串、使用小的可调用对象。这需要你了解你所用的标准库实现的SOO阈值（通常需要查文档或测试）。

3.3 使用std::array替代C风格数组和vector当数组大小在编译期已知且不大时，std::array<T, N>是最佳选择。它将数据完全存储在栈上或作为对象的成员，零动态分配开销，并且提供完整的STL容器接口。

constexpr size_t BufferSize = 256; std::array<char, BufferSize> localBuffer; // 栈上分配，快速安全 // 对比： // char cStyleBuffer[BufferSize]; // 也可用，但缺少STL接口 // std::vector<char> heapBuffer(BufferSize); // 不必要的堆分配

注意：过度使用大尺寸的栈数组（如int huge[1000000]）可能导致栈溢出。栈空间是有限的（通常几MB）。对于大的、编译期已知大小的数据集，如果其生命周期较长或较大，仍需考虑堆分配（如std::vector），但可以配合后面提到的预留空间技巧。

4. 技巧二：善用reserve与shrink_to_fit，驯服容器的容量增长

std::vector、std::string、std::deque等动态容器的增长策略是性能的“双刃剑”。为了平摊多次插入的成本，它们通常会采用指数级扩容（如每次扩容为当前容量的1.5或2倍）。这虽然保证了push_back的均摊O(1)复杂度，但在特定场景下会带来问题。

4.1 问题场景：不可预测的分配与拷贝/移动开销假设你从一个数据流中读取10万个整数放入vector。

std::vector<int> data; for (int i = 0; i < 100000; ++i) { data.push_back(readNextInt()); }

vector初始容量可能是0。插入第一个元素，分配容量1。插入第二个，容量不够，分配新容量（比如2），将旧元素拷贝/移动到新内存，释放旧内存。插入第三个，再次分配（容量4），又一次拷贝……在这个过程中，会发生大约log₂(100000) ≈ 17次重新分配，以及大量元素的拷贝操作。如果元素类型构造/移动成本高，这就是性能灾难。

4.2 解决方案：提前reserve如果你能提前知道或大致估计最终的元素数量，使用reserve成员函数一次性分配足够的内存。

std::vector<int> data; data.reserve(100000); // 一次分配，容量至少为100000 for (int i = 0; i < 100000; ++i) { data.push_back(readNextInt()); // 后续的push_back只有构造，没有重新分配 }

这消除了所有中间重新分配和元素搬迁的开销。即使估计不准，稍微多预留一些空间，也比反复重新分配要好。

4.3shrink_to_fit的谨慎使用与reserve相反，shrink_to_fit请求容器减少其容量(capacity)以匹配其大小(size)，释放多余的内存。这常用于容器经过大量删除操作后，希望将闲置内存归还给系统的情况。

std::vector<int> vec(1000); // ... 大量操作后，删除了900个元素 vec.erase(vec.begin() + 100, vec.end()); // size=100, capacity可能还是1000 vec.shrink_to_fit(); // 请求释放多余内存，capacity可能变为100（注意：这是非绑定的请求）

重要提示：shrink_to_fit是一个“非绑定”请求。标准库实现可以忽略它。即使被接受，它也可能触发一次内存重新分配和所有剩余元素的搬迁。因此，不要频繁调用它。通常只在容器的生命周期内，确定其大小不会再显著增长，且闲置内存确实可观时，才考虑使用。对于短生命周期容器或即将析构的容器，调用它没有意义。

4.4 对于std::string的特别提醒std::string本质上也是一个动态容器。reserve同样适用。在处理字符串拼接时，如果能够预估最终长度，先reserve可以避免多次分配。

std::string result; result.reserve(totalLength); for (const auto& part : parts) { result.append(part); }

5. 技巧三：理解智能指针的性能开销与最佳实践

智能指针是现代C++内存安全的基石，但它们并非零成本抽象。理解其内部机制和开销，是正确使用它们的前提。

5.1std::unique_ptr：近乎零开销的独占所有权std::unique_ptr在运行时通常就是包裹了一个原始指针，其析构函数会调用删除器（默认是delete）。在开启优化（如-O2）的编译器中，这些调用很容易被内联，其开销与手动调用delete几乎无异。因此，在任何可以用独占所有权表达的地方，应优先使用std::unique_ptr，它兼具安全性和高性能。

5.2std::shared_ptr：控制块的重量级成本std::shared_ptr需要维护引用计数，这个计数通常存储在一个“控制块”中。控制块还可能包含弱引用计数、自定义删除器、分配器等。创建std::shared_ptr的成本显著高于std::unique_ptr。

• 构造开销：std::shared_ptr<T> p(new T)会触发两次分配：一次为对象T，一次为控制块。
• 拷贝开销：拷贝shared_ptr需要原子地递增引用计数，这是一个原子操作，比非原子操作慢得多，在多线程环境下还可能引起缓存同步问题。

5.3 关键优化实践

1. 优先使用std::make_shared：std::make_shared<T>(args...)通常会将对象T和控制块分配在单块连续内存中。这减少了一次内存分配，提高了内存局部性（对象和控制块在一起），是首选的创建方式。

   auto sp1 = std::make_shared<MyClass>(arg1, arg2); // 推荐：一次分配 std::shared_ptr<MyClass> sp2(new MyClass(arg1, arg2)); // 不推荐：两次分配

   注意：std::make_shared的局限性在于，如果对象本身很大，或者你希望对象内存和控制块内存由不同的分配器管理，则不适合。此外，当使用std::enable_shared_from_this时，必须在类内部使用shared_from_this()，而不能在构造函数中调用。

2. 避免不必要的shared_ptr拷贝：以常量引用传递shared_ptr给函数，除非函数需要共享所有权（即需要延长生命周期）。

   void process(const std::shared_ptr<BigObject>& obj); // 好：不增加引用计数 void takeOwnership(std::shared_ptr<BigObject> obj); // 好：明确取得所有权，但有一次拷贝

   在循环内部、高频调用的函数中，尤其要注意。

3. 考虑使用std::weak_ptr打破循环引用：shared_ptr的循环引用会导致内存泄漏。使用weak_ptr来观察对象而不增加其引用计数，是解决此问题的标准方法，同时也避免了不必要的计数开销。

4. 审视是否真的需要共享所有权：很多情况下，所有权其实是独占的（unique_ptr），或者是可以明确界定的（对象在某个作用域内创建和销毁）。滥用shared_ptr会导致代码语义模糊，并引入不必要的性能负担。

6. 技巧四：针对特定模式使用自定义分配器（内存池）

当通用分配器成为瓶颈时，自定义分配器是终极武器。它并不适合所有场景，但对于有特定内存使用模式的模块，效果立竿见影。

6.1 何时需要考虑自定义分配器？

• 大量小对象的分配/释放：通用分配器对小对象的管理效率较低，内存碎片化严重。
• 固定大小对象的频繁分配：例如，网络数据包、游戏中的粒子、特定大小的业务实体。
• 对分配延迟有极端要求：如实时音频处理、高频交易。
• 希望将对象集中在特定内存区域：提高缓存局部性，或配合非易失性内存等特殊硬件。

6.2 内存池的基本思想内存池预先从系统申请一大块内存（池），然后自己管理这块内存的分配和释放。对于固定大小的对象，实现尤其简单：将池划分为一个个“块”（每个块大小等于对象大小），并用一个链表（空闲链表）串联起所有空闲块。分配就是从链表头取一个块，释放就是将块放回链表头。这几乎就是O(1)的操作，无锁或只需轻量级锁，且几乎没有碎片。

6.3 一个极简的固定大小内存池示例

#include <cstdlib> #include <new> template <typename T> class SimpleMemoryPool { public: SimpleMemoryPool(size_t chunkCount) { // 分配一大块内存，足以容纳 chunkCount 个 T 和指针 size_t chunkSize = sizeof(T) > sizeof(void*) ? sizeof(T) : sizeof(void*); pool_ = static_cast<char*>(std::malloc(chunkSize * chunkCount)); // 初始化空闲链表：将每个块的首字节当作指针，指向下一个块 freeList_ = reinterpret_cast<void**>(pool_); for (size_t i = 0; i < chunkCount - 1; ++i) { void** current = reinterpret_cast<void**>(pool_ + i * chunkSize); *current = pool_ + (i + 1) * chunkSize; } // 最后一个块指向nullptr void** last = reinterpret_cast<void**>(pool_ + (chunkCount - 1) * chunkSize); *last = nullptr; } ~SimpleMemoryPool() { std::free(pool_); } void* allocate() { if (!freeList_) { throw std::bad_alloc(); } void* result = freeList_; freeList_ = static_cast<void**>(*freeList_); // 将头指针指向下一个空闲块 return result; } void deallocate(void* ptr) { if (!ptr) return; // 将释放的块插回空闲链表头部 *static_cast<void**>(ptr) = freeList_; freeList_ = static_cast<void**>(ptr); } // 提供符合 Allocator 要求的接口（简化版） T* allocateObject() { return new (allocate()) T(); // Placement new } void deallocateObject(T* ptr) { ptr->~T(); // 显式调用析构 deallocate(ptr); } private: char* pool_ = nullptr; void** freeList_ = nullptr; }; // 使用示例 class ExpensiveObject { // ... 假设构造/析构成本高 }; int main() { SimpleMemoryPool<ExpensiveObject> pool(1000); // 分配 ExpensiveObject* obj1 = pool.allocateObject(); // 使用 obj1... // 释放 pool.deallocateObject(obj1); // 后续分配会复用刚刚释放的内存 ExpensiveObject* obj2 = pool.allocateObject(); pool.deallocateObject(obj2); return 0; }

这个示例非常基础，实际生产环境的内存池需要考虑线程安全（加锁或使用线程本地存储）、内存对齐、扩容策略、与标准库容器集成（通过提供符合Allocator概念的类型）等复杂问题。C++17引入了std::pmr::memory_resource和std::pmr::polymorphic_allocator，为使用自定义分配器提供了更标准、更灵活的方式。

6.4 使用std::pmr（多态内存资源）C++17的<memory_resource>头文件提供了一套标准化的内存分配框架。你可以创建不同的memory_resource派生类（如池式资源std::pmr::unsynchronized_pool_resource），然后将其与标准库容器关联。

#include <memory_resource> #include <vector> int main() { // 创建一个非同步的池式内存资源（单线程用） std::pmr::unsynchronized_pool_resource pool; // 创建一个使用该内存资源的vector std::pmr::vector<int> vec(&pool); // vec的所有内存分配都将通过pool进行，pool内部会管理内存池 for (int i = 0; i < 10000; ++i) { vec.push_back(i); } // 退出作用域时，vec析构，内存由pool负责释放 return 0; }

std::pmr让使用高性能自定义分配器变得前所未有的简单和标准化，是未来C++内存优化的重要方向。

7. 技巧五：优化数据结构与内存布局，榨干CPU缓存的潜力

现代CPU的缓存行（Cache Line，通常是64字节）是数据传输的基本单位。如果你的数据访问模式是随机的，或者经常需要跨缓存行获取数据，就会产生大量的“缓存未命中”（Cache Miss），导致CPU空转等待内存数据，性能急剧下降。

7.1 数据局部性原理

• 时间局部性：最近被访问的数据很可能再次被访问。循环变量、频繁使用的计数器就具有很好的时间局部性。
• 空间局部性：访问某个内存位置后，其附近的内存位置很可能也被访问。顺序遍历数组就是典型例子。

优化内存布局的核心就是提升空间局部性。

7.2 将“结构体数组”改为“数组结构体”这是一个经典优化。假设你有一个Player结构体，需要处理大量玩家。

// 传统方式：结构体数组 (Array of Structures, AoS) struct Player { Vec3 position; // 12字节 Vec3 velocity; // 12字节 int health; // 4字节 int mana; // 4字节 // ... 其他字段 }; std::vector<Player> players; // 更新所有玩家的位置 for (auto& p : players) { p.position += p.velocity * deltaTime; }

如果你的更新循环只关心position和velocity，那么每次循环迭代，CPU加载一个Player的缓存行（64字节），但只用了其中的24字节（position+velocity），health和mana等字段也被加载了，浪费了缓存空间，并且减少了真正有用的数据在缓存中的数量。

优化为“数组结构体”（Structure of Arrays, SoA）：

struct Players { std::vector<Vec3> positions; std::vector<Vec3> velocities; std::vector<int> healths; std::vector<int> manas; }; Players players; // 更新所有玩家的位置 for (size_t i = 0; i < players.positions.size(); ++i) { players.positions[i] += players.velocities[i] * deltaTime; }

现在，positions和velocities在内存中是连续存储的。循环遍历时，缓存行里装的全是位置数据，然后是速度数据，缓存利用率极高。这对于SIMD指令优化（如SSE, AVX）也极其友好。

7.3 警惕“假共享”假共享（False Sharing）是多线程编程中的性能杀手。它发生在两个线程各自修改同一缓存行中的不同变量时。因为缓存一致性协议是以缓存行为单位维护的，一个线程修改了缓存行中的任何字节，都会导致其他CPU核心中该缓存行的副本失效，迫使它们重新从内存加载，即使它们修改的是不同变量。

struct SharedData { int counterA; // 线程1频繁修改 int padding[16]; // 填充，确保counterA和counterB不在同一缓存行 int counterB; // 线程2频繁修改 };

通过填充（Padding）将可能被不同线程高频修改的变量隔离到不同的缓存行，可以消除假共享。C++17引入了std::hardware_destructive_interference_size来获取缓存行大小，可以用于指导填充。

7.4 对齐控制使用alignas关键字或编译器属性来控制对象或成员的对齐方式，可以确保数据被放置在对其访问最有利的地址上。例如，SSE/AVX指令要求数据按16/32字节对齐。

struct alignas(32) AVXVector { // 确保整个结构体32字节对齐 float data[8]; };

对于动态分配的内存，C++17提供了对齐版本的new和std::aligned_alloc。

8. 实战问题排查与性能分析工具指南

知道了技巧，但在实际项目中如何定位内存性能问题？盲目优化往往事倍功半。你需要工具和科学的方法。

8.1 性能剖析工具

• CPU Profiler：如perf(Linux)、Instruments(macOS)、VTune(Windows/Linux)。它们能告诉你程序时间花在了哪里。如果发现malloc、free、operator new或某个分配器函数占据了很高的CPU时间，那内存分配就是瓶颈。
• 内存分析器：
  • Valgrind Massif：堆内存分析工具，可以生成内存使用快照，显示哪些调用路径分配了最多内存。
  • Heaptrack(Linux)：图形化堆内存分析器，可以跟踪所有内存分配和释放，找出内存泄漏和分配热点。
  • AddressSanitizer (ASan)：不仅仅是内存错误检测器，其malloc/free的替换实现也带有性能开销统计，可以辅助发现分配频率过高的问题。

8.2 常见问题模式与排查思路

1. 性能热点在new/delete：使用性能分析器确认。然后审查热点代码：

   • 是否在紧凑循环中分配了大量小对象？考虑使用栈变量、对象池或复用对象。
   • std::vector等容器是否在循环中push_back导致反复扩容？添加reserve。
   • 是否使用了大量std::shared_ptr且频繁拷贝？尝试改为传递引用，或用std::unique_ptr重新设计所有权。

2. 程序运行一段时间后变慢：可能是内存碎片化。对于长时间运行的服务，通用分配器的碎片化问题会逐渐显现。监控进程的RSS（常驻内存集）是否持续增长，而实际有效内存使用量稳定。考虑使用针对长期运行优化的分配器，如jemalloc或tcmalloc，它们通常比系统自带的malloc有更好的碎片整理策略。

3. 多线程程序扩展性差：可能是分配器锁竞争。通用分配器为了保证线程安全，内部有全局锁或细粒度锁。当大量线程同时分配内存时，锁竞争会成为瓶颈。使用线程本地缓存的内存池（每个线程有自己的小内存池），或者使用像tcmalloc这样对多线程优化较好的分配器。

4. 缓存未命中率高：使用perf等工具可以查看缓存未命中事件（如cache-misses）。如果很高，结合代码审查：

   • 是否在遍历链表等非连续数据结构？考虑改为数组或std::vector。
   • 结构体是否过大且访问模式稀疏？考虑按SoA方式重组数据。
   • 多线程变量是否有假共享？使用缓存行填充。

8.3 一个简单的自定义分配器性能对比测试当你怀疑通用分配器是瓶颈，并打算引入自定义分配器时，一个简单的基准测试是必要的。你可以使用Google Benchmark库。

#include <benchmark/benchmark.h> #include <vector> #include <memory> #include “你的内存池.h” // 包含你实现的内存池 struct SmallObject { char data[32]; }; static void BM_StdAllocator(benchmark::State& state) { for (auto _ : state) { std::vector<SmallObject*> ptrs; ptrs.reserve(state.range(0)); for (int i = 0; i < state.range(0); ++i) { ptrs.push_back(new SmallObject); } for (auto p : ptrs) { delete p; } } } BENCHMARK(BM_StdAllocator)->Arg(1000)->Arg(10000); static void BM_CustomPool(benchmark::State& state) { SimpleMemoryPool<SmallObject> pool(state.range(0)); // 使用前面示例的简单内存池 for (auto _ : state) { std::vector<SmallObject*> ptrs; ptrs.reserve(state.range(0)); for (int i = 0; i < state.range(0); ++i) { ptrs.push_back(pool.allocateObject()); } for (auto p : ptrs) { pool.deallocateObject(p); } } } BENCHMARK(BM_CustomPool)->Arg(1000)->Arg(10000); BENCHMARK_MAIN();

运行这个测试，你可以直观地看到在特定场景（大量固定大小小对象的分配/释放）下，自定义内存池相对于标准new/delete的性能提升。记住，任何优化都要有数据支撑，而不是凭感觉。

9. 总结与进阶思考

优化从来都是权衡的艺术。内存管理优化也不例外。你在追求性能的同时，可能会牺牲一些代码的简洁性（如SoA比AoS更繁琐）、通用性（自定义分配器往往针对特定场景），或者增加调试复杂度。

我的经验是，遵循“先测量，后优化”的原则。不要一开始就追求极致的优化。先用清晰、正确、符合现代C++惯用法的代码实现功能。然后，在性能剖析工具的指导下，找到真正的瓶颈。接着，应用我们今天讨论的这些技巧中最对症下药的一两种。很多时候，仅仅是添加一个reserve，或者将一处关键的shared_ptr传递改为常量引用，就能解决80%的性能问题。

对于更复杂的系统，内存管理会成为架构设计的一部分。你可能需要设计多级内存池、考虑内存的NUMA亲和性、或者集成第三方的高性能分配库（如jemalloc,tcmalloc,mimalloc）。C++标准库也在不断演进，std::pmr是一个重要的方向，它让定制化分配更容易融入现有代码。同时，密切关注语言发展，比如C++20/23中关于静态反射、执行器等提案，未来可能会提供更优雅的元编程方式来辅助内存布局优化。

最后，保持学习和对底层的好奇心。理解计算机体系结构（尤其是内存层次结构）、操作系统内存管理机制，会让你在优化时更有方向感。内存管理是现代C++程序员从“合格”走向“资深”的必经之路，它没有终点，但每深入一步，你对程序的控制力就更强一分。