还是得看场景，如果说是要确保用户名（或者其他作为 key 的字段）唯一的场景下，明显 Map 比 List 合适。

这两句解析后没有区别，去看看别的地方吧

同好奇怎么判断是否浏览过。。。点开看了一眼算么

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

@shm7 https://github.com/Lambda-3/Graphene 知识图谱相关的用 java 写的还是不少的。就算是 object detention，YOLO 也是拿 c 写的，python 也就在上面封一层。

感觉现在有些人做科研写 python 写多了，还能写出我就是无可取代的错觉，呵呵

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

补一个邮件列表的链接： 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 之类的