提交了一个 PHP 不需要源代码文件直接执行编译后的 opcode 文件的 PR，反对者不少啊

[szopen]

感兴趣的可以参与讨论，我英文不好，与其他人沟通好难
github PR:
https://github.com/php/php-src/pull/6146
也可以到 PHP internals 邮件列表中参与讨论

[CismonX]

PHP 的 GitHub 仓库只是个镜像，走正规流程的话，需要找一个官方开发者作为你的 sponsor，帮你提 RFC，然后会内部讨论，后面会投票。等到正式实装（希望渺茫），可能十年过去了。

我建议还是写个 PHP module，然后投稿到 PECL，被采纳的几率大一些（也需要 sponsor ）

[secondwtq]

就目前的讨论来讲感觉还是很正常的… 并没有出现特别大的问题

[jhdxr]

补一个邮件列表的链接： https://externals.io/message/111965

其次这个不算一个正式的 RFC，如果想写 RFC 请参考 https://wiki.php.net/rfc/howto

最后，我尝试总结并翻译一下邮件中其他人提到的疑问（因为这也好几天前的邮件了，我不记得当时有看到作者或者其他人给出强有力的解答）

『 OPCache 本身并没有保证实现的稳定性，换言之，某个版本编译出来的 opcode，在下一个版本（包括小版本），甚至对于 nightly 来说，某几个提交后，就不能够执行了。PHP 目前自己的做法是如果失效了就直接从源文件（.php ）生成一份新的 opcode 。但是对于你这个提交，因为没有源文件，那这个问题怎么解决？』

nikita 提出了关于应用场景的问题。因为如果是想尝试取代分发源文件的形式去部署应用，那意味着需要去保证 opcache 生成出来的 opcode （在不同版本间）的稳定性，这几乎是不可能的（工作量太大，没人想去做）。如果只是为了冷启动的性能，那么这个方案与现有的文件缓存相比优势在何处

如果是商业软件为了避免源码泄露采取这种方式，有人提到结合 docker 似乎可以（因为相当于把 php 解释器本身也固定下来了）←我个人并不认为这是一种值得尝试的做法。一来如果你真想这么做现在就可以了。二来更新使用的解释器版本更多的是为了避免潜在的 bug，因此用 docker 不代表就应该不更新版本了


To 楼主，如果你能够回复上面引号内的那个问题，并且说服我的话。我可以帮你去进行沟通 /创建 RFC 之类的

[zjsxwc]

所以我选择混淆源代码，逃

[abersheeran]

@CismonX PHP 社区原来是这个氛围的吗？有新想法还得有一个有资历的人带过去？搞这一套这不是欺负新人吗？

[jhdxr]

@abersheeran hmm，实际上新建 RFC 是不需要的。任何人都可以向 internal 邮件组发邮件，说明自己想要提一个新的 RFC，并且简要说明你打算写什么相关的（一句话即可，说清楚就行，不需要证明合理、有用等等，反正我还没见过申请 wiki 账号被拒绝的），然后就会拥有一个 wiki 账号，就可以按照我在 3 楼发的链接自己去新建 RFC 并且完成
@CismonX 提到的一系列流程了。其中，只有投票这一步，是有资格要求的。
又或者，你对弄一个自己的 RFC 不感兴趣，只是想有事没事去吐槽一下别人的 RFC （参与讨论），那就更简单了，订阅 internal 的邮件列表就可以回邮件参与讨论了。

[szopen]

@jhdxr 我写的这个，应当是 opcache 扩展的一个小补丁，所以并能保证各个版本下 opcode 的兼容。
关于引号中说的问题，这个补丁目前给出的方法是判断版本是否匹配，不匹配会给出版本错误提示（或者禁止执行），然后尝试执行，不匹配执行产生的任何后果由使用者承担。
出现错误，使用者或开发者应当更换与之匹配的版本来执行 opcode 文件。
补丁默认情况下是禁止直接执行 opcode 的，需要在配置项中开启，所以可以认为直接执行 opcode 文件的人应当是知道后果的。
我也是一时兴起，所以，如果你感兴趣、有空闲时间，可以帮助提交一下。

[jhdxr]

@szopen 在你描述的前提下，你这个 PR 的应用场景是？『如果只是为了冷启动的性能，那么这个方案与现有的文件缓存相比优势在何处』