1. 原代码的安全性判断 #

这段通过MySQLi查询users表且无用户输入变量的代码，确实天然具备SQL注入防护能力。SQL注入的核心是攻击者通过可控输入篡改SQL语句的结构逻辑，而如果SQL语句完全是硬编码、没有拼接任何外部传入的变量，攻击者根本没有篡改语句的入口，自然不存在注入风险。

2. 无用户输入场景是否需要Prepared Statements？ #

不是必须，但有可选价值：

• 从安全角度：完全没必要，因为没有用户输入带来的风险点。
• 从性能/规范角度：如果后续可能多次执行相同结构的查询，Prepared Statements可以让数据库预编译SQL，提升重复执行的效率；另外如果团队有统一的代码规范要求所有数据库操作都用预处理，那可以遵循规范，但这和防注入无关。

3. 应聘者该怎么应对？ #

别上来就直接改成Prepared Statements交差——这会显得你没搞懂SQL注入的本质。正确的操作是：

• 先跟招聘方说清楚：这段代码因为没用到任何用户输入的变量，SQL语句是完全固定的，根本不存在SQL注入风险，本身就是安全的。
• 点出需求可能的问题：要么是出题时的疏漏，要么就是故意考察你对SQL注入原理的理解，而不是只会照搬防护手段。
• 分情况展示你的能力：
  • 针对当前无输入的代码：可以提一些非安全相关的优化，比如完善错误处理、整理代码结构之类的。
  • 专门写一个有用户输入的场景示例：比如按用户ID查询的功能，用MySQLi Prepared Statements来实现，展示你怎么正确用预处理防注入。

这样既显得你懂行，又能证明你真的会用防护技术，比盲目改代码靠谱多了。

内容的提问来源于stack exchange，提问作者kamilio3214