使用这种方法有什么根本缺陷吗？
您首先要了解的是，$pdo 是 存储 逻辑的一部分。这意味着，它只能在执行抽象数据访问的类中使用，无论是 SQL 表还是集合。
让我们看看你的代码，
function somefunction(){
global $pdo;
$statement = $pdo->prepare("some query");
$statement->execute();
}
如果您将来想从 MySQL 切换到 Mongo/MSSQL/PgSQL，该怎么办？
那么你将不得不重写很多代码。
对于每个数据库供应商，您必须创建一个具有不同变量的单独文件。就这样
function somefunction(){
global $mongo;
return $mongo->fetch(...);
}
通过使用全局状态，最终会导致大量代码重复，因为您无法传递参数，因此无法在运行时更改函数的行为。
现在让我们看看这个，
function somefunction($pdo){
$statement = $pdo->prepare("some query");
$statement->execute();
}
这里，$pdo 作为参数传递，因此没有全局状态。但是问题依然存在，你最终违反了单一职责原则
如果你真的想要一些可维护、干净且可读性强的东西，你最好坚持使用DataMappers。这是一个例子，
$pdo = new PDO(...);
$mapper = new MySQL_DataMapper($pdo);
$stuff = $mapper->fetchUserById($_SESSION['id'])
var_dump($stuff); // Array(...)
// The class itself, it should look like this
class MySQL_DataMapper
{
private $table = 'some_table';
private $pdo;
public function __construct($pdo)
{
$this->pdo = $pdo;
}
public function fetchUserById($id)
{
$query = "SELECT * FROM `{$this->table}` WHERE `id` =:id";
$stmt = $this->pdo->prepare($query);
$stmt->execute(array(
':id' => $id
));
return $stmt->fetch();
}
}
结论
不管你的项目是小是大，你都应该避免使用所有形式的全局状态（全局变量、静态类、单例） - 为了代码的可维护性
您必须记住，$pdo 不是您业务逻辑的一部分。它是存储逻辑的一部分。这意味着，在您开始使用业务逻辑（例如繁重的计算）之前，您应该真正抽象表访问（包括 CRUD 操作）
将data access abstraction 和computation logic 连接在一起的桥梁通常称为Service
您应该始终将 things 函数的需要作为参数传递
您最好停止担心您的代码并开始考虑抽象层。
最后，在你开始做任何事情之前，你首先要初始化bootstrap.php中的所有服务，然后根据用户的输入（$_POST或$_GET）开始查询存储。
就像，
public function indexAction()
{
$id = $_POST['id']; // That could be $this->request->getPost('id')
$result = $this->dataMapper->fetchById($id);
return print_r($result, true);
}