写代码时，变量怎么命名看起来是个小事，但用错了可能埋下安全隐患。比如在团队协作中，一个人写 userpassword，另一个人写 UserPassword，结果调接口时拼错字段，敏感信息漏传，漏洞就这么来了。这时候，统一的命名规范就显得特别重要，而驼峰法就是最常用的一种。
什么是驼峰法？
驼峰法（Camel Case）就是把多个单词组合成一个变量名，第一个单词首字母小写，之后每个单词首字母大写，中间不加空格或下划线。比如：userName、loginStatus、isVerifiedUser。这种写法清晰又紧凑，是前端和Java等语言里的主流风格。
还有一种叫“大驼峰法”（PascalCase），首字母也大写，常用于类名，比如 UserInfo、AuthService。虽然只差一点，但在实际项目里区分清楚能减少误解。
为什么它和网络安全有关？
很多人觉得命名只是风格问题，其实不然。混乱的命名会让代码难读，审查时容易漏掉关键逻辑。比如有人写 user_name，有人写 username，还有人写 UserName，同一个功能散落在不同命名下，后期做权限校验或日志审计时就容易出错。
更危险的是，如果变量名含糊不清，比如用 temp、data 这种名字存用户输入，开发人员可能忘记做安全过滤，导致SQL注入或XSS攻击。而像 sanitizedInput 或 escapedQuery 这样的驼峰命名，一看就知道经过处理，提醒自己和同事别乱用。
实战中的正确打开方式
假设你在写一个登录函数，接收用户名和密码。用驼峰法命名参数，代码会更清晰：
function authenticateUser(userName, userPassword) {
if (!isValidFormat(userName)) {
logInvalidAttempt(userName);
return false;
}
const encryptedPass = hashPassword(userPassword);
return verifyCredentials(userName, encryptedPass);
}这里的 userName、userPassword、encryptedPass 都符合小驼峰规则，语义明确，不容易拼错。别人看代码时一眼就能看出数据流向，审计起来也方便。
反观如果写成 un、pw 或 User_Name，不仅难读，还可能在拼接SQL时手滑写成 WHERE username = '${un}'，留下注入风险。
团队协作更要统一标准
很多安全问题不是技术不够，而是沟通出错。新成员加入项目，看到一堆命名不一致的变量，根本搞不清哪个是原始输入，哪个是过滤后的。如果全队都用驼峰法，并配合 ESLint 这类工具强制检查，能大幅降低误操作概率。
比如规定所有用户输入必须以 raw 开头，如 rawInput、rawQuery，处理后变成 cleanInput、sanitizedQuery，这样一目了然，谁都不敢直接拿原始数据去查数据库。
命名看似是小事，但在代码安全里，每一个清晰的标识都在帮你避开陷阱。别小看一个驼峰，它可能是堵住漏洞的第一道防线。