php manual mysqli page讨论了混合面向对象和程序样式，并说为了代码清晰度和编码风格的原因，不推荐混合使用这两种样式。＆＃34;
我维护并更新了一个大约10年前的大型项目（成千上万的代码行），至少会继续这么多。 （如果你愿意的话，把它看成是一种图像CMS。）所有现有的mysqli代码都是程序化的，大部分都是从最初使用的旧的mysql扩展中改变的。 （并且在大多数情况下仍然可以完美地运行。）项目代码模块可以根据需要进行更新，添加，删除和/或替换，因此我将在该项目上进行多年的零星工作。 / p>
为了清晰，简洁和可维护性，我想将其切换为OO样式。与从mysql到mysqli的变化不同，只需要一点点思考和大量全局搜索/替换就不会轻易完成。一次改变整个项目并不是一个有吸引力的选择。简单地与程序性的mysqli一起生活可能是最节省时间的，但是我不介意把工作放在更好的地方，只要我不做所有这一切马上。
仅更改项目的一部分是否切实可行，将其他部分保留为程序样式，直到它们重新写入为止？
这里有什么问题？什么东西可以自由混合，什么东西不能组合OO和程序mysqli？
编辑：为了清楚起见，我并没有问到广泛的风格问题，纯粹是为了将OO风格和程序风格调用混合到mysqli扩展中。除了一个平淡无奇的声明之外，该手册不包含任何内容，并且可以随时在样式之间切换。没有提供任何有用的细节。
答案 0 :(得分：2)
混合OO和过程样式没有错。正如引文所说，“出于代码清晰和编码风格的原因，不建议这样做。”
但是，如果您从mysql_*迁移到mysqli_*时所做的只是全局搜索，而只是为了更改函数名称而进行替换，那么您真的错过了新API的全部重点。
这个想法是，在进行迁移时，您应该实现准备好的语句并清除mysql_*函数通常是罪魁祸首的混乱的意大利面条代码。坚持程序风格完全没有好处，甚至使代码更加复杂。当以OO样式使用时，准备好的语句和异常要干净得多。
如果不使用参数绑定和mysqli异常，则最好坚持使用mysql_*函数。