之前做的一些项目，一般自己整理结构的时候都这么来：
/application
____/pc
________/controllers
________/views
____/mobile
________/controllers
________/views
/system
____/library
____/models
____/services
____system.php
/public
____/pc
________/assets
________index.php
____/mobile
________/assets
________index.php
/upload
/data
(不好意思，这个神编辑器的 UL/OL 真的用不来)
application：应用目录，system：系统目录，public：网站入口，upload：上传目录，data：缓存session等。
主域名绑定到 /public/pc 下，移动域名绑定到 /public/mobile 下，各自的 index.php 定义各自 application 路径，来给路由指明相应的 /Controllers 和 /views，另外都require 系统入口 /system/system.php 来实现常量定义、初始化和启动应用。
因为是一个数据库，所以 /models 放到了 /system 里面公用，model 只是单纯的表映射和 set/get/CURD 方法，为了最大程度的复用（比如 pc 站和移动站都需要某个模块的发布功能），业务操作直接移到 /services 里面，action 只做最简单的参数过滤、调用 service 执行业务、redirect。
立即学习“PHP免费学习笔记（深入）”；
问题来了：
最近打算做一个游记类的网站，可以肯定的是只有 pc 端和移动端，暂不考虑 APP 应用，本来是考虑按照上面的单入口来的，但是网站功能真的很有限，几个入口完全可以胜任，而且多入口省去了路由操作直接进业务逻辑可以压榨一部分性能，单入口的参数虽然可以用 htaccess 改一下但肯定没有多入口简洁明了。多入口每个头里面 require 系统核心 system.php 一样可以实现系统初始化、参数过滤、类库函数库加载的一些功能。
因为网站完全自己一个人做，团队协作根本不存在，那这样的：多入口+系统入口包含+services+DAO 是不是一样可以做到 pc 站和移动站的复用（感觉按照最上面的形式，不一样要写两遍 Controllers 么...），另外最重要的一点，有没有单入口是不是影响负载均衡包括数据库主从等的实现呢（因为从来没有过这方面的场景）？
其实我主要纠结的就是两点：1、复用（直接写死的话混写一路到头当然效率要高一些，但是移动端再重新写一遍确实有点傻）；2、性能性能性能，和将来可能的抗压能力。
回复内容：
之前做的一些项目，一般自己整理结构的时候都这么来：
/application
____/pc
________/controllers
________/views
____/mobile
________/controllers
________/views
/system
____/library
____/models
____/services
____system.php
/public
____/pc
________/assets
________index.php
____/mobile
________/assets
________index.php
/upload
/data
(不好意思，这个神编辑器的 UL/OL 真的用不来)
application：应用目录，system：系统目录，public：网站入口，upload：上传目录，data：缓存session等。
主域名绑定到 /public/pc 下，移动域名绑定到 /public/mobile 下，各自的 index.php 定义各自 application 路径，来给路由指明相应的 /Controllers 和 /views，另外都require 系统入口 /system/system.php 来实现常量定义、初始化和启动应用。
因为是一个数据库，所以 /models 放到了 /system 里面公用，model 只是单纯的表映射和 set/get/CURD 方法，为了最大程度的复用（比如 pc 站和移动站都需要某个模块的发布功能），业务操作直接移到 /services 里面，action 只做最简单的参数过滤、调用 service 执行业务、redirect。
立即学习“PHP免费学习笔记（深入）”；
问题来了：
最近打算做一个游记类的网站，可以肯定的是只有 pc 端和移动端，暂不考虑 APP 应用，本来是考虑按照上面的单入口来的，但是网站功能真的很有限，几个入口完全可以胜任，而且多入口省去了路由操作直接进业务逻辑可以压榨一部分性能，单入口的参数虽然可以用 htaccess 改一下但肯定没有多入口简洁明了。多入口每个头里面 require 系统核心 system.php 一样可以实现系统初始化、参数过滤、类库函数库加载的一些功能。
因为网站完全自己一个人做，团队协作根本不存在，那这样的：多入口+系统入口包含+services+DAO 是不是一样可以做到 pc 站和移动站的复用（感觉按照最上面的形式，不一样要写两遍 Controllers 么...），另外最重要的一点，有没有单入口是不是影响负载均衡包括数据库主从等的实现呢（因为从来没有过这方面的场景）？
其实我主要纠结的就是两点：1、复用（直接写死的话混写一路到头当然效率要高一些，但是移动端再重新写一遍确实有点傻）；2、性能性能性能，和将来可能的抗压能力。
首先回答你的标题问题
PHP单入口是否是必须的
答案肯定不是，之所以单入口比较多的原因在于大多数流行的框架都是单入口的模式，至于优劣你已经有仔细考量过了，并且这个优劣也是智者见智，仁者见仁，就不做展开了。
1、复用（直接写死的话混写一路到头当然效率要高一些，但是移动端再重新写一遍确实有点傻）；
这个你也说了，程序执行效率 - 程序员维护效率，这是一个不可调和的矛盾，在这个矛盾下一定是
- 执行效率高 维护效率低
- ...(各种折中)
- 执行效率低 维护效率高
无论是哪种语言还是设计决策，其实都是在找折中点，你要确定你的折中点在哪里，有时候牺牲一些性能，但是带来维护效率的提高，那么其实也不是不可以接受
拿你的这个多入口来说，无非就是在你的多个业务相同的入口内include相同的逻辑（极端情况把相同的逻辑变成一个后，又是你之前的模式），你可以将单入口“请求”抽象，设计成“业务请求”，在这个方向上进行你的逻辑微调，这就是你的多入口模式
2、性能性能性能，和将来可能的抗压能力。
80%的性能问题都不在php程序本身，而在于php和php所连接的资源（例如mysql，file存储），与其考虑php的问题，不如好好想想怎么优化php对资源的访问效率，如果优化php对资源的访问效率到极致以后，或许你会采用phalcon或者直接把php替换成另外一个编译语言
单入口方便管理
康盛的uchome 和 discuz!都不是单入口的!
