StringTokenizer解析ARCHIVE_FILE_EXTENSION_FILTER时首个值异常返回NULL

触发该问题的核心原因是传给env.getProperty()的查询key，经过trimIni方法处理后，与配置文件中定义的实际配置key完全不匹配。
Spring的Environment接口读取配置时，对配置key是做全字符串严格匹配的，只要key存在哪怕一个字符的差异——比如trimIni处理时裁剪了key前缀、替换了字符、调整了大小写、误加了空格——接口就会因为找不到对应配置项直接返回null，根本不会进入后续的后缀分割逻辑。
从现有代码逻辑判断，本质是搞反了方法的使用顺序：trimIni这类清理类方法的设计初衷是清理配置值的首尾空白，本应在getProperty拿到原始配置值之后调用，对取出的值做清洗；但当前代码把trimIni直接作用在配置key上，处理后的key和配置文件中写的Text.FileArchiver.INV_ARCHIVE_FILE_EXTENSION_FILTER无法匹配，最终触发返回NULL。

• 方法使用顺序颠倒：混淆了配置查询、配置值清洗的执行顺序，把本该作用于接口返回值的清理方法用在了查询参数上，直接引发配置匹配失败。
• 后缀分割逻辑存在缺陷：即使正常拿到配置值，使用StringTokenizer按逗号分割时，不会自动剔除每个分割片段的前后空白。比如配置值done , proc分割后得到的两个结果会是"done "、" proc"，携带多余空格，后续做文件后缀匹配时会因为字符串不匹配出现逻辑失效。
• 数组初始化逻辑冗余：代码中先声明了一个空的字符串数组，后续再根据token计数重新初始化数组长度，这部分逻辑不仅冗余，还容易因为token计数的临时变动出现数组长度不匹配、数组越界的问题。
• 缺少配置加载的兜底提示：当配置key匹配失败返回null时，没有添加对应的日志输出标记异常的配置项，排查问题时无法快速定位是配置缺失、配置加载不全还是key拼写错误。

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