授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。
一、先别急着说“没生效”：把现象拆成三层
1.1 同一句“没变化”，可能来自三个不同的地方
你在自建靶场里改了一行 PHP，保存，刷新浏览器，页面和改之前一模一样。多数人的第一反应是“代码没生效”，接着开始怀疑环境、怀疑版本、怀疑自己是不是改错了文件。问题在于，“没生效”这三个字把三种完全不同的情况揉成了一句，而这三种情况的排查方向彼此不重叠，顺序错了就找不到。
第一种在文件层：你以为改的是 A，程序读的是 B。靶场目录里常常同时躺着解压出来的一份、你复制出来的一份、Web 根目录下软链指向的一份；编辑器保存的是你打开的那一份，服务读的是另一份。这一层的特征是，改完之后连你自己都对不上——明明加了一行，行为却像那行从来没存在过。
第二种在执行层：文件确实是那一份，内容也确实变了，但负责执行它的进程手里还留着上一次的编译结果，没有重新读这个文件。这一层才是 OPcache 站的位置，也是本文的全部范围。
第三种在呈现层：请求已经拿到新结果，你看到的却是旧的——浏览器把上一个响应留在本地，中间还可能有代理替你回话。这一层的特征是换个客户端就露馅，换一个浏览器，画面忽然就对了。
1.2 三层的判据不一样，所以顺序不能乱
区分这三层靠的不是猜，而是各有各的观察点。文件层看时间戳：这个文件最后一次被写入是什么时候，和你保存的时间对不对得上。执行层看配置：那个进程到底有没有被要求去比对时间戳。呈现层看客户端：换一个完全没缓存的客户端再发一次请求，结果变不变。
文件层那一步，命令本身很短，短到没有理由跳过。
⚠️代码待验证
stat-c'%y %n'/var/www/html/index.phpstat-f'%Sm %N'/var/www/html/index.php顺序之所以重要，是因为三层成本差别很大：看文件时间戳一条命令，看配置一条命令；唯独“怀疑缓存、然后动手收拾”这一步，一旦方向错了，你会把本来没问题的运行时状态搅乱，之后连“改之前是什么样”都说不清了。所以本文后面所有内容都建立在同一个前提上：先用最便宜的方式把层分对，再谈层内怎么办。
1.3 为什么执行层这一层最难自己发现
因为它不报错。文件层的错往往带症状——路径不对、读到的不是你想读的那份；呈现层的错换个客户端就现形；唯独执行层是“安静地给你一个旧结果”。屏幕上没有任何一行字提示你“看到的是旧的编译版本”，只有一种模糊的“好像没变”。
初学者在这里最常见的动作是反复保存、反复刷新，然后在“有时候变了、有时候没变”的错觉里越走越远。这个错觉恰恰有解释：两个以秒为单位的时间窗在互相叠，第三章再展开。
1.4 本文的边界
这里先把话说死：本文只讲 OPcache 缓存了什么、靠什么判断文件变了、关掉判断之后会发生什么，以及一条从便宜到贵的自查顺序。本文不给“改哪一个配置项就解决”的结论——那需要对你那台机器的完整运行状态负责，而本文只对着手册与默认值讲话。
二、被缓存下来的到底是什么
2.1 一次请求里，编译这一步是可以省掉的
PHP 执行一个脚本，粗略分成两段：先把源码读进来，做词法分析、语法分析，翻译成一串中间指令；再把这串指令交给执行器跑。第二段每次都得跑，省不掉；第一段的结果却只跟文件内容有关——只要文件没变，翻译出来的东西就不会变。
于是就有了一个很自然的想法：把第一段的结果留下来。PHP 手册在opcache.enable这一项里把这件事说得很直白，默认值是1：
Enables the opcode cache. When disabled, code is not optimised or cached. The setting
opcache.enablecan not be enabled at runtime through ini_set(), it can only be disabled. Trying to enable it in a script will generate a warning.
这段话里有两个点值得停。第一，它叫 opcode cache，缓存的对象是 opcode，也就是编译产物，不是文件内容本身。第二，这个开关的运行时行为不对称：脚本里能关掉，却打不开，试图打开只会得到一条警告。换句话说，进程启动时没开缓存，在业务代码里怎么折腾都补不回来。
2.2 缓存的单位是脚本，键是路径
同一页手册里，opcache.max_accelerated_files的说明是：
The maximum number of keys (and therefore scripts) in the OPcache hash table.
这句话把结构和单位一起交代了：缓存是一张哈希表，表里的键对应脚本，所以脚本数量有上限，默认10000。与之配套的opcache.memory_consumption默认128，单位是 MB，手册同时注明最小可取值是8。
这两项放在一起说明，缓存不是“无限大的一层”，而是一段有容量、有条目上限的存储。超了会存不下——手册只讲到这一步，至于存不下时具体怎么处理，本文不复述，也不推测，因为那不是这几条原文能支撑的结论。
2.3 命中缓存时，被跳过的是哪一步
这一点值得单独强调，因为它直接决定了你会看到什么。假设文件内容已经改了，但缓存没有失效，那么接下来的请求里，进程不会去读那个文件、不会重新编译，而是直接执行手里那份旧的 opcode。
所以你看到的现象，准确描述不是“旧文件被读出来了”，而是“新的文件根本没被读到”。文件系统上那份文件是新的，磁盘上的字节是新的，编辑器里显示的也是新的，唯一还是旧的，是进程内存里那段已经翻译好的指令。明白这一层，你就不会再去删文件重写——文件从来不是问题所在。
想验证这个判断，最直接的办法是问那个进程：你手里那段缓存现在是什么样。
⚠️代码待验证
php-r'var_dump(opcache_get_status(false)["opcache_enabled"]);'2.4 一张表：缓存里有什么、没有什么
| 对象 | 在不在缓存里 | 它变了，缓存会自动知道吗 |
|---|---|---|
| 源文件的字节内容 | 不在，缓存的是编译产物 | 不自动知道，要靠时间戳比对 |
| 编译出来的 opcode | 在，存在共享内存段里 | 它自己不“变”，只能被替换 |
| 文件的修改时间 | 不缓存，每次校验时现读 | 这正是校验的依据 |
| 脚本的路径（键） | 在，作为哈希表的键 | 换路径等于换键，是另一条记录 |
| 运行时的变量、会话 | 完全不在，与缓存无关 | 无关，别往这里找原因 |
三、两种校验：时间戳与“文件够不够旧”
3.1 validate_timestamps：决定“要不要去看”
缓存要能被更新，前提是进程愿意花一点代价去确认文件动过没有。这个意愿由opcache.validate_timestamps控制，默认1：
If enabled, OPcache will check for updated scripts every opcache.revalidate_freq seconds. When this directive is disabled, you must reset OPcache manually via opcache_reset(), opcache_invalidate() or by restarting the Web server for changes to the filesystem to take effect.
这段话已经把全文骨架给出来了：默认开着；开着时每隔一段时间查一次；关掉后，文件改动要生效只剩“手动复位”和“重启 Web 服务器”两类动作。第四章、第五章分别展开这两半。
同一页还有一条容易被跳过的 Note，恰恰是最容易让人困惑的地方：
OPcache may still validate the timestamp of a file at compile-time if opcache.file_update_protection or opcache.max_file_size options are set to non-zero values.
也就是说，即使你把周期性校验关了，只要另外那一项还是非零，编译那一刻仍可能做一次时间戳判断。这句话的存在，说明“关掉校验”并不等于“系统里再没有任何时间戳比对了”，它只是去掉了周期性那一层。
3.2 revalidate_freq：那个“2 秒”
opcache.revalidate_freq的默认值是2，手册原文：
How often to check script timestamps for updates, in seconds.
0will result in OPcache checking for updates on every request.
单位是秒，0意味着每个请求都查。同一项下还有一句限定：
This configuration directive is ignored if opcache.validate_timestamps is disabled.
把它和上一条拼起来，你就得到一张很清楚的分工表：validate_timestamps管“查不查”，revalidate_freq管“多久查一次”。前者是 0 的时候，后者连被读取的机会都没有。
对初学者最实际的含义是：改完立刻刷新，和隔几秒再刷新，可能不是同一个结果。不是浏览器在骗你，是你正好落在两个校验周期之间。很多人因此得出“刷新要刷好几次才生效”的经验，那条经验的真实内容其实是“你刷得太快了”。
3.3 file_update_protection：另一个“2 秒”，方向相反
opcache.file_update_protection的默认值也是2，但它的含义不是“多久查一次”，而是“多新的文件先别缓存”：
Prevents caching files that are less than this number of seconds old. It protects from caching of incompletely updated files. In case all file updates are atomic, performance can be increased by setting this to
0. This will allow files to be cached immediately.
设计意图写得很清楚：防止把一个“改到一半”的文件缓存进去。编辑器保存大文件时、某些工具先截断再写入时，文件在极短的时间里是不完整的；如果这个瞬间被抓去编译，缓存里就留下了一份半成品，而它看起来完全正常。
按手册这条说明可以推：改动后不到 2 秒的文件不会被缓存。于是这就出现了两个方向相反的时间窗——一个让改动“更快被看见”，一个让改动“暂时不进入缓存”。它们叠在一起，正好解释那种反复现象：刚保存完刷一下是新的，过一会儿再看又像旧的。
这三个值在同一台机器上的当前取值，可以一次问出来。
⚠️代码待验证
php-i|grep-E'opcache\.(validate_timestamps|revalidate_freq|file_update_protection)'3.4 一张表：两个 2 秒各管什么
| 指令 | 默认值（截至 2026-10-20 手册配置表） | 管的是 | 调小会怎样 |
|---|---|---|---|
| opcache.validate_timestamps | 1 | 要不要周期性比对时间戳 | 不是数值项，只有开与关 |
| opcache.revalidate_freq | 2秒 | 两次比对之间隔多久 | 趋近每次请求都查，代价上去了 |
| opcache.file_update_protection | 2秒 | 多新的文件先不缓存 | 趋近 0，改动更快进缓存，也更容易撞上半成品 |
| opcache.enable | 1 | 整个缓存功能的总闸 | 不是数值项，关掉等于不用缓存 |
四、把校验关掉：省下的是什么，付出的是什么
4.1 关掉之后，改动靠什么生效
把validate_timestamps设为 0，周期性比对就没了。按手册原文，此后文件的改动要生效，只剩三种动作：opcache_reset()、opcache_invalidate()，或者重启 Web 服务器。
注意这三个动作的共同点：它们都不是“让系统自己发现”，而是“由你告诉系统，别信手里那份了”。前者是自动机制，后者是人工干预。这不是好坏之分，是两种不同的运行假设——一种假设“文件会随时被改”，另一种假设“文件在进程生命周期内是固定的”。
4.2 代价一：文件的改动不再自动可见
这是最直接的一层。在开发环境里，你每次保存都期望下一次请求就是新代码；一旦关掉校验，这个期望就不成立了。你会进入一种奇怪的状态：文件明明是新的，行为却一直停在某个时间点，而且这个时间点跟你的保存动作没有对应关系，只跟“上一次复位是什么时候”对应。
更麻烦的是它表现得飘：同一份代码，复位之后是对的，过一段时间有人改了文件，它又错位了，而你未必知道那次改动。等到问题暴露，你面对的是“两份都正确过的代码”，却分不清现在跑的是哪一份。
4.3 代价二：可观察的东西少了一层
排查问题时，我们其实很依赖“时间戳比对还在不在”这件事。它在的时候，你能通过“改了没变 / 改了变了”这个对比，快速判断问题是不是在缓存层；它不在的时候，这个对比失效了——不管你怎么改，结果都不变，你没法用“改一下试试”这种手段来分辨原因。
这就是为什么很多人在关掉校验之后，排查能力反而下降了。不是知识不够，是手边少了一个能给出反馈的探针。
4.4 这不是性能开关，是可见性开关
初学者常把这类配置理解成“快一点 / 慢一点”的旋钮，于是觉得“关掉比较快，那就关掉”。但按前面几条原文看，它改变的不是速度，而是文件系统与执行内容之间那条同步线还在不在。线在，你改文件，进程迟早知道；线断了，只有你主动去接，它才知道。
至于断掉之后性能省了多少，本文不给数字——本机没有 PHP 二进制，任何收益量化都是无依据的推测。
4.5 一张表：校验开着与关掉，机制上的差别
| 维度 | 校验开着（默认） | 校验关掉 |
|---|---|---|
| 文件改动怎么被看见 | 周期性比对时间戳，默认每 2 秒一次 | 不会自动被看见 |
| 改动生效需要什么 | 等一个周期即可 | 手动复位，或重启 Web 服务器 |
| 编译期是否仍可能比对 | 可能，取决于另外两项是否非零 | 同样可能，取决于另外两项 |
| 排查时能否用“改一下试试” | 可以，改动能给出反馈 | 不行，改动不产生可观察差异 |
| 适合的运行假设 | 文件会随时被改 | 文件在一段时期内固定 |
五、想让 OPcache 重新看见文件，机制上有哪几条路
5.1 路一：等，让周期校验自己发生
最省事的一条路是什么都不做。只要validate_timestamps是开着的，revalidate_freq到点，进程就会去比对一次时间戳，发现不一样就重新编译。你要做的只是把“立刻刷新”改成“过一会儿再刷新”。
这条路的前提是那个开关没被关掉。它一旦是 0，这条路直接不存在——revalidate_freq会被忽略，你等多久都没用。
5.2 路二：主动复位，三种粒度
手册列出的三个动作，其实是三种不同的粒度。opcache_invalidate()针对单个脚本，颗粒最细；opcache_reset()针对整段缓存，一刀切；重启 Web 服务器则连进程带内存一起换掉，最彻底，代价也最大。
粒度越细，你越需要知道“到底该让哪一条失效”；粒度越粗，你越不需要判断，但顺手牵连的东西也越多。初学者容易直接跳到最粗的那一档，因为它不需要想清楚问题在哪——可这也意味着，你放弃了“通过复位范围反推问题范围”的机会。本文只讲这三档的差别，不复述任何一条命令的执行结果。
动手之前，先确认这两个入口在这份构建里存在。
⚠️代码待验证
php-r'var_dump(function_exists("opcache_reset"), function_exists("opcache_invalidate"));'5.3 路三：从源头避开“半成品被缓存”
file_update_protection这一项严格说不是“让改动生效”的路，而是“让改动不至于被错误地缓存”。手册给了两个方向：保持默认的 2 秒，容忍一点延迟，换来“不会缓存到改到一半的文件”；或者在确认所有写入都是原子时设为 0，让文件立刻可被缓存。
注意措辞：设为 0 得到的是“立刻可被缓存”，不是“立刻刷新”。这两件事经常被混为一谈。前者说的是新文件不必等在门外，后者说的是旧条目会不会被替换——那是validate_timestamps的地盘。把它们当成同一个旋钮，是这一章最容易犯的错。
5.4 三条路的共同点
先把这几种做法放在一张表里对照，差别会更清楚。
| 这条路 | 作用粒度 | 依赖什么 | 代价 |
|---|---|---|---|
| 等一个校验周期 | 该更新的那几条缓存条目 | validate_timestamps为 1 | 改动不是立刻可见 |
| 主动复位 | 整段缓存或单个脚本 | 你要判断得出问题范围 | 每次都得有人记得做 |
| 重启 Web 服务器 | 整个进程 | 一个可接受的停服窗口 | 牵连最大，现场全丢 |
| 调整保护窗 | 新建条目进入缓存的时机 | file_update_protection的取值 | 只是换了取舍方向 |
三条路没有一条是“改一个值，从此不用管”。路一要一个没被关掉的开关配合，路二每次都得有人记得去做，路三换的是一个取舍方向而不是消灭问题。这也是本文不给确定结论的原因：三条路对应不同的运行假设，选哪条取决于你把机器当开发机还是当长期不动的服务，判断只能你自己做。
把这三条路的机制、默认值和适用前提压成了一页对照，放在资料包里：
OPcache 校验机制对照页：把
enable、validate_timestamps、revalidate_freq、file_update_protection四项的默认值、作用范围和相互忽略关系整理成一页，配合本文第三章、第五章看更顺。放在资料包里，扫码即可获取：
六、CLI 与 Web：同一份代码，两个执行现场
6.1 enable_cli 默认是关的
opcache.enable_cli的默认值是0，手册说明只有一句：
Enables the opcode cache for the CLI version of PHP.
默认关，意味着你在命令行里跑同一个脚本时，通常根本没有这层缓存。这一项还有一条 Changelog，值得记一下：
Between PHP 7.1.2 and 7.1.6 inclusive, the default was
1
也就是说，在 7.1.2 到 7.1.6 之间默认值是 1，后来改回 0；截至 2026-10-20 手册仍这样记。照那个年代的笔记配环境，很可能对不上现在的默认行为——不是你操作错了，是默认值变过。
6.2 为什么“命令行是新的，浏览器是旧的”
这是初学者最常撞见的一组对照：php yourscript.php跑出来是新结果，浏览器一刷还是旧的。有人据此认为是浏览器缓存，清了一遍没用；又怀疑是 Web 服务器缓存，换个思路还是不对。
能确定的部分是：命令行那个进程默认没开这层缓存（enable_cli默认0），每次现读现编译；Web 那一侧由另一个进程处理请求，它的opcache.enable默认是1。两边从默认值起就不在同一状态，结果不同并不奇怪。
至于这两个进程是不是各自持有一段互不相干的缓存、命令行进程退出后它那段是不是就随之消失——这一点标「待验证」：手册没有就这一处逐字说明，本文也没有实测（本机没有 php 二进制）。所以本文只把“默认值不同”当作可用的结论，“两段内存互相独立”只作为一个待核实的推测摆在这里，不作为判断依据。
6.3 该怎么用这组对照
即便结论只到“默认值不同”这一步，这组对照依然有用：它给了你一个几乎零成本的分层手段。同一份文件，命令行跑是新的、Web 跑是旧的，说明文件层基本可以排除，问题落在 Web 那一侧的执行层或呈现层；两边都是旧的，那更可能是文件层——你改的根本不是被读的那份。
6.4 一条只读的观察命令
想看两个现场各自的状态，最直接的办法是分别问它们：命令行一侧直接问，Web 一侧看它加载的那份配置。
⚠️代码待验证
php-i|grep-E'opcache\.(enable|enable_cli)'php--inips-eopid,args|grep-E'php-fpm|php '|grep-vgrep两种方式的共同点：问的是“那个进程看到的”，不是“配置文件里写的”——配置可能有多份，加载的只有一份。
七、自查顺序：从最省钱的一步开始
7.1 五步，按成本从低到高
把这篇文章收成一套可执行的动作，顺序是这样的。
第一步，确认你改的是同一份文件。看它的最后修改时间和你保存的时间对不对得上；看 Web 根目录下那个路径是不是软链。这一步成本最低，却最容易被跳过。
第二步，确认这次请求真的由 Web 那一侧处理。同一份文件用命令行跑一遍，两边结果对不上，说明分叉点在执行侧，而不是文件侧。
第三步，看validate_timestamps是不是 1。这是整条链路上的总闸，它若为 0，后面两步都没意义。
第四步，看那两个 2 秒。改完立刻刷新，你可能正好落在revalidate_freq的周期里；也可能是文件太新，被file_update_protection挡在缓存门外，表现又不一样。
第五步，才是复位。走到这一步说明前四步都排除了，你确实遇到了“缓存里有旧条目且不会自动更新”的情况。这一步放在最后，是因为它代价最高，而且它会覆盖现场。
7.2 每一步的判据
| 步骤 | 看什么 | 结果指向哪里 |
|---|---|---|
| 一 | 文件最后修改时间、真实路径 | 对不上就是文件层，与缓存无关 |
| 二 | 命令行与 Web 两侧结果是否一致 | 一致偏文件层，分叉偏执行层 |
| 三 | validate_timestamps的当前值 | 为 0 则自动更新这条路不存在 |
| 四 | revalidate_freq与file_update_protection | 决定你要等多久，而不是要不要等 |
| 五 | 复位后行为是否变化 | 变了说明此前确实是旧条目在跑 |
7.3 什么时候该怀疑缓存之外的东西
有两种情况说明你找错方向了。一种是：复位后立刻正确，过一段时间又错位，而这期间确实有人改过文件——不是缓存的错，是运行假设（第四章那条同步线）和你的工作方式不匹配。另一种是：无论怎么改、怎么复位，结果都不动——那基本可以排除缓存层，回到第一章的第一层去看路径和副本。
7.4 一句话收束
OPcache 带来的困惑，几乎都来自同一个错位：你以为自己在改“程序”，其实你改的是“程序的源代码文件”，而正在跑的是那份文件的编译结果。这两者之间靠时间戳连着，默认每 2 秒确认一次；线在，改动迟早会过去；线断了，就得有人手动接。把这个模型记住，剩下的都是查默认值。
到这里，机制部分就讲完了。附表 A 把每条事实和官方出处逐条对上，方便复核；附表 B 是术语速查，遇到不熟的词直接翻。
配套资料获取：把本文用到的四项 OPcache 配置、两个 2 秒的关系、以及 CLI 与 Web 的默认值差异整理成了一页速查，放在资料包里，扫码即可获取：
附表 A：本文引用事实与官方出处对照表
| # | 事实（照口径） | 一手出处 | 本文位置 |
|---|---|---|---|
| 1 | opcache.enable默认1；运行时只能关不能开，脚本内打开会产生警告 | www.php.net《OPcache 运行时配置》 | 第 2 章 |
| 2 | opcache.validate_timestamps默认1；关闭后须opcache_reset()、opcache_invalidate()或重启 Web 服务器 | www.php.net《OPcache 运行时配置》 | 第 3、4、5 章 |
| 3 | 同页 Note：file_update_protection或max_file_size非零时，编译期仍可能校验时间戳 | www.php.net《OPcache 运行时配置》 | 第 3 章 |
| 4 | opcache.revalidate_freq默认2秒；取0表示每次请求都检查 | www.php.net《OPcache 运行时配置》 | 第 3 章 |
| 5 | revalidate_freq在validate_timestamps关闭时被忽略 | www.php.net《OPcache 运行时配置》 | 第 3 章 |
| 6 | opcache.file_update_protection默认2秒；全原子更新时可设0，让文件立即被缓存 | www.php.net《OPcache 运行时配置》 | 第 3、5 章 |
| 7 | opcache.enable_cli默认0；7.1.2 至 7.1.6 期间默认为1 | www.php.net《OPcache 运行时配置》 | 第 6 章 |
| 8 | opcache.memory_consumption默认128（MB，最小值8）；max_accelerated_files默认10000，为哈希表键数上限 | www.php.net《OPcache 运行时配置》 | 第 2 章 |
| 9 | 推论：缓存对象是编译产物；改动可见性依赖时间戳校验；关闭校验后只能复位或重启 | 由第 1、2、4 行原文推出，非独立事实 | 第 2、4 章 |
| 10 | 推论：不足 2 秒的文件不进缓存，与 2 秒校验周期叠加，可解释“刚改完是新的、过一会儿又变旧” | 由第 6 行原文说明推出，非独立事实 | 第 3 章 |
| 11 | 待验证：CLI 与 Web 进程是否各持独立共享段、CLI 退出后是否消失 | 手册未逐字说明；本文未实测（本机无 php 二进制） | 第 6 章 |
| 12 | 全文凡“截至”类时间表述，统一锚定 2026-10-20 | 本文标注约定 | 全文 |
附表 B：术语速查表
| 术语 | 一句话解释 |
|---|---|
| OPcache | PHP 的 opcode 缓存扩展，把编译结果留在共享内存里，省掉后续请求的编译步骤 |
| opcode | 源码经过词法、语法分析后得到的一串中间指令，是执行器真正要吃的东西 |
| 编译产物 | 本文对 opcode 的另一种叫法，强调它“来自文件但不等于文件” |
| validate_timestamps | 决定要不要周期性比对文件时间戳的开关，默认开 |
| revalidate_freq | 两次时间戳比对之间隔多少秒，默认 2；0 表示每次请求都查 |
| file_update_protection | “多新的文件先别缓存”的保护窗，默认 2 秒，防的是改到一半的文件 |
| 共享内存段 | 缓存实际待着的地方，一段由进程共用、不随单个请求消失的内存 |
| 复位 | 本文对opcache_reset()、opcache_invalidate()这类动作的统称，分整段与单文件两种粒度 |
| CLI 与 Web SAPI | 同一个 PHP 的两种执行现场，前者跑命令行脚本，后者接 Web 请求，默认配置不同 |
| 时间戳校验 | 用文件的修改时间判断“这个文件是不是还是编译时那一份”的机制 |
| 运行假设 | 本文用词，指你默认“文件会不会随时被改”，决定了关不关校验更合适 |
| 截至 2026-10-20 | 本文所有默认值与时序表述的统一锚定日期 |
写在最后：这篇用到的资料
写这篇文章时，我把 PHP 手册 OPcache 配置页里那几项挨着读了一遍，发现“改了没变”这件事，官方原文其实一句一句都写过，只是分散在
enable、validate_timestamps、revalidate_freq、file_update_protection四处，没人替你串起来，于是顺手也整理了几份配套的东西：
- 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
- Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
- 常用靶场清单：每个靶场练什么、适合哪个阶段
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「靶场」，优先通过。
拿到之后建议先看靶场环境对照表那一份，把靶场目录、Web 根路径、软链指向三栏填清楚——本文第一章说的“改的是不是同一份文件”，靠的就是这三栏。
