restrict是C99标准引入的一个类型限定符，和const、volatile属于同一类语法元素，但很多C程序员对它相当陌生。它的作用说起来很简单：向编译器做出一个承诺——通过restrict指针访问的内存，在指针的生命周期内不会被其他指针以别名的方式访问。编译器正是基于这个承诺，才有底气进行更激进的优化。如果代码违反了这个承诺，结果是未定义行为，程序可能正常运行，也可能产生难以排查的错误。
指针别名问题为什么拖慢了程序
要理解restrict的价值，得先搞清楚指针别名（aliasing）这个概念。所谓别名，就是两块不同的指针指向了同一块内存。看下面这个经典例子：
void add_arrays(int *a, int *b, size_t n) {
for (size_t i = 0; i < n; i++) {
a[i] = a[i] + b[i];
}
}
这段代码看起来一目了然，但编译器却不敢轻举妄动。问题在于a和b可能指向重叠的内存。假如b恰好指向a+1的位置，那么修改a[i]就会影响后面要读取的b[i+1]，两次循环迭代之间存在数据依赖。编译器无法证明这种重叠不存在，只能保守地按顺序逐个元素处理，无法把循环向量化，也无法把多次内存访问合并。
这种保守策略在高性能场景下代价巨大。现代CPU支持SIMD指令，一条指令可以处理4个甚至8个int的加法。如果没有别名问题，编译器可以把上面的循环改写成向量化版本，理论上获得数倍的性能提升。但由于指针别名的存在，这些优化全部无法实施，这就是restrict要解决的核心痛点。
restrict的语义到底是什么
restrict的标准定义比较绕口，简单来说它包含两层承诺。第一，在指针的有效作用域内，所有通过该指针访问的内存对象，都只能通过这个指针（或者由它派生出的指针，比如ptr+i）来访问。第二，如果这块内存本身没有被const修饰，那么对它的写入和读取都必须经由restrict指针完成。
加上restrict之后，前面的函数可以改写成：
void add_arrays(int *restrict a, int *restrict b, size_t n) {
for (size_t i = 0; i < n; i++) {
a[i] = a[i] + b[i];
}
}
这时编译器获得了明确的保证：a和b不会指向重叠内存。以GCC为例，使用-O2或更高优化级别时，编译器会将这个循环自动向量化，生成SSE或AVX指令。需要注意restrict只是给编译器的承诺，编译器不会在运行时检查承诺是否被遵守，检查责任完全在程序员身上。
一个常见的误解是restrict修饰的是指针本身，其实它修饰的是指针与内存块之间的访问关系。restrict指针可以指向只读内存，也可以参与指针运算，派生出的别名（例如p+1）是合法的，只要所有访问最终都能追溯到这个restrict指针即可。真正禁止的是从其他完全独立的途径访问同一块内存。
restrict带来的实际性能差异
来看一个内存拷贝的对比实验，环境为GCC，开启-O3优化，数据量为1亿个int：
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
// 普通版本，编译器无法确定是否重叠
void copy_plain(int *dst, const int *src, size_t n) {
for (size_t i = 0; i < n; i++) {
dst[i] = src[i];
}
}
// restrict版本，向量化得以实施
void copy_restrict(int *restrict dst, const int *restrict src, size_t n) {
for (size_t i = 0; i < n; i++) {
dst[i] = src[i];
}
}
int main(void) {
size_t n = 100000000;
int *src = malloc(n * sizeof(int));
int *dst = malloc(n * sizeof(int));
for (size_t i = 0; i < n; i++) src[i] = i;
clock_t t1 = clock();
copy_plain(dst, src, n);
clock_t t2 = clock();
copy_restrict(dst, src, n);
clock_t t3 = clock();
printf("普通版本: %.3f 秒\n", (double)(t2 - t1) / CLOCKS_PER_SEC);
printf("restrict版本: %.3f 秒\n", (double)(t3 - t2) / CLOCKS_PER_SEC);
return 0;
}
典型测试结果中，restrict版本的耗时大约是普通版本的三分之一到二分之一。普通版本因为无法排除dst和src重叠的可能，只能用安全的标量拷贝或者带运行时重叠检测的memcpy语义；而restrict版本被直接向量化，每次搬运一整块数据，内存带宽利用率大幅提升。
C标准库中的很多函数原型本身就使用了restrict，比如memcpy的两个指针参数都带restrict限定，而memmove则没有。这正是两者语义差异的体现：memcpy要求源和目标区域不重叠，因此可以走最快的路径；memmove允许重叠，必须先检测再决定拷贝方向，性能稍逊一筹。理解了这一点，也就理解了restrict在API设计中的实际价值。
使用restrict时容易踩的坑
restrict最大的风险在于违反承诺属于未定义行为，而且症状往往很隐蔽。比如函数内部定义的两个局部指针都带restrict，却让它们指向了同一块内存，在-O0下可能一切正常，一旦开启-O2，编译器基于错误假设做的优化就会导致数据错乱，而且这种bug通常无法稳定复现。
还有一个容易忽视的细节是struct成员。如果把restrict用在结构体成员上，承诺的范围是每次使用该成员的那个结构体对象的生命周期。此外，restrict并非C++标准的一部分，如果你写的代码要和C++混合编译，需要用宏定义做条件处理，例如通过#ifndef __cplusplus来包裹restrict关键字，或者干脆使用编译器扩展关键字如__restrict，主流编译器对它的支持更广泛，包括MSVC。
实践中有几条建议可以遵循：只在确实存在性能瓶颈的热点函数上使用restrict；使用前后做性能对比，确认优化真实生效；确保调用方永远不会传入重叠的指针；必要时在调试构建中加入断言检查重叠情况。restrict是一把双刃剑，用对了能让代码白拿性能，用错了则是埋进程序里的定时炸弹。把它当作一份严肃的契约来对待，才能安全地享受它带来的收益。
restrict关键字C语言指针指针优化修改时间：2026-09-07 04:44:29