处理Java项目里的SQL注入问题，这个修复流程值得收藏
先说几个核心判断：文心快码企业版要真正用起来，得先确保它跟项目接上了，然后才是定位漏洞、一键修复、验证闭环。这篇内容把完整链条拆开来讲，希望对正在做安全整改的开发者有所帮助。
先确认文心快码企业版已接入Java项目
开胃菜：项目根目录下是不是已经存在 【.wenxin/config.yaml】 这个文件？如果找不到，说明基础接入还没完成，后面所有扫描动作都没法触发。
接下来跑一条验证命令：./gradlew wenxinScan。观察控制台输出，重点关注有没有类似 “Loaded 127 Java source files” 的行——只有出现明确的源文件计数，才代表解析器已经成功加载了业务代码。
定位高危SQL拼接点
进入文心快码企业版Web控制台，左侧导航栏找到「漏洞图谱」→「SQL注入」，系统默认按风险等级降序排列。一眼扫过去，优先紧盯标记为「Critical」的那些节点，尤其是调用链里出现 Statement.executeQuery() 或 createStatement().executeQuery() 的——这类位置基本就是原始拼接SQL的老巢。
但有一点必须强调：【绝不可跳过人工复核】。对每个高危节点点击「查看上下文」，直接定位到Java文件的具体行数。如果你看到类似 "SELECT * FROM user WHERE name = '" + name + "'" 这种字符串拼接，恭喜你，找到必须修复的注入点了。
一键替换为PreparedStatement（推荐方法）
在漏洞详情页点击「智能修复」按钮，选择「Java PreparedStatement」模板。
文心快码会自动分析原SQL结构、参数个数及变量类型，生成带占位符的语句和绑定逻辑。举个例子：
String sql = "SELECT * FROM users WHERE id = " + userId;
stmt.executeQuery(sql);
会被替换为：
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setLong(1, userId);
自动生成不是万能的。完成替换后，务必手动检查一下 setXxx() 方法的参数类型是否与数据库字段定义一致——如果数据库id是BIGINT但工具生成了 setInt()，运行时会直接报错。这个细节很容易被忽略。
对MyBatis项目启用安全增强模式
如果你的项目用了MyBatis，有两种思路可以走。
方法一：在 【mybatis-config.xml】 中添加全局配置：${} 动态拼接，仅允许 #{} 参数化引用。
方法二：如果项目走注解方式，检查所有 @Select、@Update 注解里是否还残留 ${tableName} 这类写法。文心快码企业版会在「MyBatis风险项」子页面单独列出这些点，全都必须改为 #{tableName} 或迁移到 @Param 注解传参。
但有个坑要提示一下：开启 safeMode 之后，原来依赖 ${} 实现表名或字段名动态切换的逻辑会直接报错。你需要同步重构为 TableNameProvider 等白名单机制，不要指望一劳永逸。
验证修复效果
修复完了不等于万事大吉，验证环节必须走完。
第一步：执行 ./gradlew wenxinRescan，等待扫描完成。
第二步：在控制台「修复验证」页签，确认原漏洞ID的状态已经变为「已修复」，而且「验证请求」列显示绿色勾选图标。
第三步：也就是最实战的一步——本地启动应用，用Burp Suite向对应接口发送含单引号的请求，比如 username=admin' OR '1'='1。观察响应体，如果返回空结果或400错误，说明防护生效了；如果依然返回用户数据，说明修复还没到位，需要回去排查。
以上几步走下来，SQL注入的修复流程就算闭环了。从接入确认到漏洞定位，再到一键修复和安全模式启用，最后验证收尾——这套流程跑熟之后，效率会提升不少。