一、include是什么：从“文本插入”说起

在软件工程中，代码复用与模块化是控制复杂度的两大基石。include（包含）正是支撑这一目标的基础机制：它是一条指令或语言结构，用于在预处理或运行阶段，把指定文件的内容“插入”到当前文件中，使当前文件能够直接使用被包含文件中定义的常量、宏、函数、类与接口声明等成分。

include并非某一种语言独有：在C/C++中，它以预处理指令#include的形式存在；在PHP中，它是语言结构include；在JSP等服务端技术中，也有对应的包含指令与包含动作。形态各异，核心思想却一致——“把别处写好的内容，按既定规则合并进当前文件的编译或执行上下文”。理解它在什么阶段发生、以什么方式合并、会带来哪些副作用，是用好这门机制的关键。

二、C/C++中的#include：预处理器的文本替换

1. 两种语法形式与搜索路径差异

C/C++标准规定了两种写法：

#include <stdio.h>      /* 形式一：尖括号 */
#include "myheader.h"   /* 形式二：双引号 */

两者语义相同，都是“包含指定文件”，差别在于预处理器搜索文件的路径顺序不同：

• 尖括号形式：优先在编译器预置的标准库及系统头文件目录中查找，通常用于包含标准库或外部依赖的公共头文件；
• 双引号形式：一般先从当前源文件所在目录（以及项目显式配置的本地包含路径）开始查找，找不到时再回退到系统路径，通常用于包含项目内部自定义头文件。

需要说明的是，具体搜索顺序由各编译器实现自行决定，标准只要求双引号形式优先搜索“实现定义的位置”。因此大型项目应通过构建配置显式声明包含路径，而不是依赖隐式查找行为。

2. 本质是文本级拷贝

include的处理发生在预处理阶段：预处理器逐行扫描源代码，遇到#include时，就把目标文件的全部内容原样展开到当前位置，并递归处理其中可能存在的进一步包含。理解这一“纯文本替换”的本质非常重要：

• 预处理阶段不进行语法检查与类型检查，包含的内容只是被“搬运”进来；
• 头文件中的所有宏、声明都会进入当前编译单元，进而影响后续编译行为；
• 过深、过广的包含链条会直接推高编译时间，是大型项目构建缓慢的常见原因之一。

3. 头文件的内容边界

按照惯例，头文件中应放置“接口成分”：类型与函数声明、宏定义、内联函数与模板定义等；而函数实现、全局变量定义等“实现成分”应放在源文件中。如果把定义放进头文件并被多个源文件包含，很容易在链接阶段触发重复定义错误。

4. 重复包含与头文件保护符

同一个头文件可能通过不同路径被间接包含多次，导致其中的类型或宏被重复定义。标准做法是使用“包含保护符”：

#ifndef MY_PROJECT_UTILS_H
#define MY_PROJECT_UTILS_H
/* 头文件实际内容 */
#endif

此外，许多主流编译器还支持#pragma once这一非标准但被广泛实现的写法，语义等价且书写更简洁。工程中二选一并全项目统一即可，不建议混用。

5. 常见陷阱

• 循环包含：A包含B、B又包含A，可通过前向声明打破循环，把依赖降到最低；
• 隐式依赖：代码依赖“被其他头文件顺带包含”进来的声明，一旦上游重构便编译失败，应显式包含所有直接用到的头文件；
• 路径歧义：同名头文件存在于多个目录，实际包含来源与预期不符，应统一路径规范并定期清理冗余包含。

三、PHP中的include：运行时求值的表达式

1. 基本语法与执行流程

与C/C++在编译期展开不同，PHP的include发生在运行期：

include 'path/to/config.php';

解释器执行到该语句时，按给定路径查找文件，找到后将其内容纳入当前脚本求值；若文件不存在，产生警告后继续执行。一个关键特性是：被包含代码继承调用点处的变量作用域。也就是说，包含文件内可以直接访问调用方已有的变量，其中新定义的变量也会在调用方后续代码中可见；若在函数体内包含，则作用域限定在该函数内。

2. 通过return返回值

被包含文件可以执行return语句并向调用方返回数据：

/* config.php */
return ['env' => 'production', 'debug' => false];
/* main.php */
$cfg = include 'config.php';
echo $cfg['env'];

这使include天然适合承载“返回配置数组的配置文件”，是一种常见的实践模式。

3. include_once：规避重复包含

PHP不会自动防止重复包含。若同一文件被包含两次，其中的函数或类定义会因重复声明而报错。为此，语言提供了include_once：执行时先检查目标文件是否已被包含过，已包含则直接跳过，从而避免重复定义错误。对称地还有require_once，兼顾“必须包含”与“只包含一次”两个约束。

4. include与require的区别

两者的核心差异在于失败处理：

• include：目标文件缺失时产生警告，脚本继续向下执行；
• require：目标文件缺失时产生致命错误，脚本立即终止。

经验法则：缺失后脚本无法正常工作的“硬依赖”用require系列；缺失也能容忍的“软依赖”才用include。

5. 安全红线：绝不包含用户可控输入

如果包含路径由外部输入拼合（例如把请求参数直接拼进include路径），攻击者可能诱导脚本包含非预期文件，造成敏感信息泄露甚至代码执行风险，这就是典型的文件包含漏洞。正确做法是：包含目标一律由服务端白名单决定，任何外部输入都不得直接参与路径拼合。

四、JSP中的include：静态包含与动态包含

JSP同样提供包含能力，并按发生阶段分为两类：

• 静态包含（包含指令）：在页面翻译阶段把被包含文件的内容直接合并进当前页面，两者最终翻译为同一个整体，思路与C/C++的文本替换一致，适合共享声明与公共布局片段；
• 动态包含（包含动作）：在请求处理阶段把请求交给被包含页面执行，再把输出结果合并进响应，两个页面彼此独立、可以传递参数，适合组合各自独立的页面输出。

选择依据很直接：要“合并代码”用静态包含，要“合并执行结果”用动态包含。

五、跨语言的共性最佳实践

1. 职责单一：每个被包含文件只承载一个明确主题，避免“万能头文件/万能公共文件”随项目膨胀变成无人敢动的雷区；
2. 路径显式化：统一路径规范（如以项目根为基准的相对路径，或集中配置的包含路径），杜绝“恰好能找到”的隐式依赖；
3. 幂等包含：C/C++用包含保护符，PHP用*_once系列，保证同一文件被多次包含不产生副作用；
4. 显式依赖：用到什么就显式包含什么，不依赖传递包含带来的“顺带效果”；
5. 安全可控：运行期语言的包含目标必须由服务端决定，外部输入只能用于数据，不能用于路径；
6. 关注构建效率：合理拆分头文件、削减不必要的传递包含、善用前置声明，往往能显著缩短大型项目的编译时间。

六、小结

include看似只是“插入一个文件”的简单指令，实则贯穿了预处理模型、作用域规则、编译单元组织乃至安全边界等多个维度。从C/C++的编译期文本替换，到PHP的运行期求值与作用域继承，再到JSP的静态/动态双轨机制，不同语言依据自身的编译与执行模型给出了不同实现，但“显式、幂等、最小化”的原则始终通用。把这门基础机制用对、用稳，代码才能在项目规模增长后依然保持清晰、健壮与可维护。