奇葩用户名致深夜苦寻，耗时两时终得果？

标题：奇特用户名引发深夜寻找，耗时两小时终有结果？

大家好呀，我是R哥。

前几天看到一个帖子，标题一下就让我乐了。

当下，像字符串"null"、"undefined"这类巧妙设置的用户名，能让你瞬间愣住，接着可能要通宵调试好几个小时。

举个例子，用户注册时输入这样的内容：

{
  "username": "null",
  "password": "123456"
}

要是后端有这样的判断逻辑：

if (user.getUsername() == null) {
    throw new IllegalArgumentException("用户名不能为空");
}

那这个JSON发往后端时，上面的代码不会触发异常，因为字符串"null"是合法字符串，数据库里就会多出个用户名是null的“幽灵用户”，但日志里还查不到它，还以为是系统产生的异常用户呢。

用户名是"null"会有啥问题？

“null”并非null，却能带来比null更多麻烦

1、从用户体验方面

用户名是用来标识用户身份的，要是叫"null"，普通用户看到会很困惑：

欢迎您，null！

看到这样的用户名是不是感觉很奇怪？有些用户压根不知道"null"是啥意思，说不定是误操作、自动填充或者系统导入数据时弄出来的。

2、从开发和维护方面

比如在某个功能里，要是username是"null"，日志里打印的就是：

当前用户名为：null

你根本没法区分它到底是字符串"null"，还是字段真的为空。

而且还会引发不少其他问题：
- 在数据库里查重、导出Excel、做权限审核时，碰到"null"用户，根本没法判断这是不是异常数据；
- 很多自动化脚本或者系统工具对"null"都有特殊处理，有可能误判或者跳过这个用户。

3、从系统安全方面

有些攻击者会专门用"null"、"undefined"、空格、emoji这类边界值来试探系统的防御机制。

另外，"null"作为特殊标识符，在某些技术框架里会被当作系统变量、占位符来处理，有可能带来潜在的 XSS / 信息泄露风险。

4、从一致性和规范方面

要是系统允许"null"当用户名，那是不是也得允许：
- "undefined"
- "0"
- 空格" "
- emoji"💩"
- "admin"（可不是真的管理员）
- ……

还有更多乱七八糟、不规范的用户名是不是都能允许呢？

5、从排查问题方面

为了排查"null"引发的这类问题，你可能得：
- 抓包，分析请求；
- 排查后端日志；
- 在代码里加一堆断点；
- 清理缓存；
- 排查数据库看有没有空值，就算看到null值，也很难分清它到底是真的为null还是字符串null；
- ……

折腾半天，一通操作下来，才发现原来它不是null，而是"null"，然后就得修复bug、做数据清洗，一搞就是一个通宵。

该怎么正确处理"null"用户名？

虽然从技术角度讲，字符串"null"是一个合法的非空字符串，不会触发null判断，也不会让程序直接报错，但是从产品体验、安全性、运维排查等多个角度来看，这个值得当作非法输入来主动拦截。

必须对用户名做更严格的校验，比如：

private static final Set<String> ILLEGAL_USERNAMES = new HashSet<>(Arrays.asList(
    "null", "undefined", "true", "false", "admin", "root", "", " ", "\t", "\n"
));

public void validateUsername(String username) {
    if (username == null || ILLEGAL_USERNAMES.contains(username.trim().toLowerCase())) {
        throw new IllegalArgumentException("用户名非法或为空");
    }
}

示例代码，仅供参考。

有一回开发后台管理系统，运营在批量上传用户时，Excel里有个单元格是空的，他以为空着就不导入了。结果用Apache POI解析出来后，那个单元格读出来的是字符串"null"，是不是挺离谱？

于是后台就多了几个用户名叫null的运营账号，权限还不低，吓得我差点报警……

作为后端开发者，不光得写出正确的逻辑，还得能预判用户行为 + 防御边界值 + 拦住异常数据，这种合法却有隐患的字符串必须在入口就拦下来。

要是你不做拦截，系统早晚得出问题，与其事后清理、兼容，不如一开始就定好规范，用户名只能包含特定字符，长度有限制，不允许使用系统保留词或者语义不清的字符串。

所以不管数据是来自前端输入、Excel导入、接口接入，哪怕是自己写的测试脚本，都得做同样一件事：先校验，再处理，不然出了问题有的你排查。

（注：原文中的广告推荐等无关内容已过滤）