记我的第一次开源贡献：修复 Spring Cloud Alibaba 中的 Nacos 凭据泄露风险

1. 前言

最近在备战实习，作为一名 准Java 后端开发，深感简历上项目经验的不足。与其在焦虑中等待，不如主动出击。在逛 Spring Cloud Alibaba 的 GitHub Issue 列表时，我偶然发现了一个被标记为 good first issue 的任务（#4242），这成了我开源之路的起点。

2. 发现问题

该 Issue 指出，NacosConfigProperties 在调用 toString() 输出日志时，会直接打印明文的 accessKey 和 secretKey。在生产环境下，这些敏感信息如果被日志收集系统（如 SLS）抓取，将面临严重的凭据泄露风险。

我觉得这是一个非常典型且有意义的安全修复场景，于是便开始着手完成这个任务。

3. 解决过程

3.1 逻辑实现

我 Fork 了源码，在 NacosConfigProperties 中新增了一个私有的 mask() 辅助方法：

private static String mask(String value) {
    return (value == null || value.isEmpty()) ? value : "******";
}

该方法保留了 null 值以便于调试（区分“未配置”和“已配置”），而对非空敏感字段进行脱敏处理。随后，我更新了 toString() 方法，对 accessKey、secretKey `进行了掩码输出。

3.2 补齐单元测试

提交 PR 后，维护者（Reviewer）反馈非常及时，建议补充单元测试。

虽然这是我第一次接触该项目的测试代码，但我参考了项目现有的测试结构，基于 AssertJ 编写了 NacosConfigPropertiesTest 类。通过断言验证了敏感信息在 toString 中已被替换为 ******，同时确保非敏感字段（如 serverAddr）依然正常显示。

4. 成功合并

经过 Review 和交流，我的改动最终获得了维护者的 LGTM (Looks Good To Me) 认证，并被正式 Merged 进 2025.1.x 分支。

5. 感悟与总结

这次经历让我受益匪浅：

• 行动是焦虑的解药：从“不敢动手”到“代码被顶级项目合并”，其实只差一个尝试。
• 工业级代码的严谨性：开源贡献不仅是写好业务逻辑，更要考虑安全性、代码风格以及测试覆盖率。
• 成就感：一想到自己的代码即将运行在无数企业的服务器上，这种反馈是任何模拟项目都无法比拟的。

感谢社区维护者的耐心评审。这只是个开始，未来我会继续深入参与到开源生态的建设中！

最后想说的一句话：
看着自己的 Commit 记录出现在顶级开源项目的首页，我知道，这只是我 Java 后端生涯的一个开始。路虽远，行则将至！

PR 链接：https://github.com/alibaba/spring-cloud-alibaba/issues/4242