include可以在JSP页面转换成Servlet之前，将JSP代码插入其中。它的主要优点是功能强大，所包含的代码可以含有总体上影响主页面的JSP构造，比如属性、方法的定义和文档类型的设定。它的缺点是难于维护只要被包含的页面发生更改，就得更改主页面，这是因为主页面不会自动地查看被包含的页面是否发生更改。
实际顺序
比如说我正在修改一个大型项目的代码。比如里面的类之间有复杂的include关系。如果我增加了新的类A，想让它在某个已有的类B中被调用。那么自然是B的头文件中include A的头文件。但是A的头文件中可能要include C类的头文件，而且很有可能C类 include了B的头文件。B类和C类之间可能有其他类构成include的链条。所以在写类A的时候如何判断这种循环include并且用前向声明forward declaration呢？
操作步骤
1. 尽量使用 forward declaration，namespace 中的 class 都可以前向声明，模板也可以前向声明，例如 class Foo; typedef std::shared_ptr FooPtr。但是 nested class 无法前向声明。
2. 保证每个构成interface的头文件都独立可用，例如 class A 的 cpp 文件第一个包含的头文件应该是 class A 的头文件，以此类推。尽量 cpp/头文件 配对：尽量每一个 class 有一个头文件和一个 cpp 文件，文件名与类名相同，仅扩展名不同。（类模板除外，没办法。）
3. include 头文件使用绝对路径，从VCS的根开始。
4. cpp 文件和头文件中写 include 时按一定的原则分组（例如本项目、本公司、第三方C++库、C++标准库、第三方C库，libc库），每组以内按字母顺序排列头文件。
5. 做到第3点之后，用简单的脚本就能生成头文件的包含关系图（Doxygen也行），然后就很容易看出循环依赖。也不难自动检测。
6. 头文件里不要埋地雷，比如修改 struct 的默认对齐方式，修改编译器的优化级别或警告级别等等
两者之间的差异决定着它们在使用上的区别。使用include指令的页面要比使用jsp:include动作的页面难于维护。前面已经说过，使用JSP指令，如果包含的JSP页面发生变化，那么用到这个页面的所有页面都需要手动更新。在JSP服务器的相关规范中并没要求能够检测出包含的文件什么时候发生改变，实际上大多数服务器页都有去实现这种机制。这样就会导致十分严重的维护问题，需要记住所有包含某一个页面的其他页面，或者重新编译所有的页面，以使更改能够生效。在这点上，jsp:include就体现出了十分巨大的优势，它在每次请求时重新把资源包含进来。在实现文件包含上，应该尽可能地使用jsp:include动作。
最后希望我的回答能帮到你
这里面最重要的是细节部分，和代码结构问题。
结构问题：
1.代码结构来自于代码组织的更大范围。提
2.倡拆除许多小的班级。扩展到多个文件。文件中并非全部。
3.这很容易说，现实中或多或少会有违法行为。例如，工程需要使用一些常量字符串（或消息的定义，或枚举值，并有多个变种）。
使用方法：
1.一个结构清晰的结构是将字符串放在同一个头文件中，这样比较起来比较容易。这样，这个字符串文件将几乎包括在内。
2.当稍后添加新字符串时，如果只添加一行，则项目几乎全部编译。这个项目大到可以读一本书。当我想偷懒的时候，我会改变它，然后编译。
3.更好的方法是根据字符串的使用来分割它。
4.例如，有一些支持库。如果你不注意，你会写一个头文件像globalutils。H，其中包含所有配套的图书馆，因为它不在乎这globalutils。H应包括。
技巧总结：
1.总之，它包含更多的资源。然而，这样，我们需要添加一个支持函数，比如旋转角的小函数，还有一个链编译。编写一个小函数只需要1分钟，编译需要30分钟。
2.我宁愿复制和粘贴小函数一次。这很容易导致代码重复。摘要应该减少头文件的重复。需要团队的人有这种意识，并意识到这是不好的。
3.我相信还有很多人，对问题认识不足，你也会被要求，作为一个不贪的方便。它直接包含一个大的头文件，它在短期内是非常方便的，它将在很长一段时间的麻烦。
了解一些C++的常用技术。我相信很多人，甚至介词陈述，都不知道。