是否首选将POST变量分配给实际变量

您可能正在运行的一个风险是处理原始用户数据，这些数据仍然保存在原始$_POST[]变量中。我倾向于将使用的所有原始数据保存到其他变量中，就像您在$username = $_POST['username']中提到的那样，这样我就可以更有效地操作和清理输入。我没有保存对全局$_POST数组所做的任何调整，而是将所有更改临时保存在一个更易于管理的范围内。

例如：

$username = mysql_real_escape_string($_POST['username']);

优于：

$_POST['username'] = mysql_real_escape_string($_POST['username']);

通常情况下，最好保持原始用户数据不变，并在其他变量中进行调整。

我看不出任何优势或劣势。一旦你开始修改值，你应该把它们放进它们自己的变量中，但如果你只是读取它们，你可以把它们留在原地。只有两点：

• 如果使用短变量名而不是$_POST[...]使源代码更可读，那么将值放入自己的变量中是一个很好的理由

• 不一定要逐个取出值，只需将数组内容分配到另一个数组中即可：

  $values = $_POST;
  // not:
  $foo = $_POST['foo'];
  $bar = $_POST['bar'];
  ...
  

当您决定实现另一种输入方法（json编码的posts、xml-rpc、soap等）时，将其分配给另一个变量会很好地为您服务。确保您在一开始就从$_POST数组中获得所需内容，并在以后使用这些值将使代码更容易与其他输入一起重用：唯一需要更改的是这些输入的实例化。

此外，通常您希望稍微更改一个值（默认trim()-ing等），这最好在局部变量上执行，而不是在$_POST数组中的项上执行。当然，在有几十个编码器的大型项目中，在我看来，始终保持收到的$_POST数组是一个很好的做法，而不是直接篡改它，这会激怒一位无可救药的调试同事。。。

风险和错误不会改变：它仍然是你永远不应该信任的用户输入，并且总是假设最坏的情况。仅凭练习并不能阻止标准SQL注入、XSS和其他攻击。

我个人不喜欢dupe变量。坚持你所得到的，直到你需要对它进行戏剧性的转换。重复的变量会使跟踪变得更加困难，只会浪费内存和时间。为什么要把沙子带到海滩上。

从tbl中选择*，其中this='".mysql_real_sescape_string（trim（$_POST['that']））。"'

就在这一天，我遇到了同样的问题，我得出的结论是，你应该始终检查索引是否存在，以防止出现"；未定义索引"；错误如果您多次使用POST数据，我建议将测试结果分配给一个新变量，因为您可能会修改POST数据：

//at least PHP 7.0.0 required
$foo = $_POST['foo'] ?? '';
$bar = $_POST['bar'] ?? '';

哪个等价于：

$foo = isset($_POST['foo']) ? $_POST['foo'] : '';
$bar = isset($_POST['bar']) ? $_POST['bar'] : '';

如果只使用POST数据一次，则可以跳过分配新变量，只使用$_POST['foo'] ?? ''作为参数。

这个解决方案就是基于这个极好的答案。进一步阅读：https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-colesce-op