关联规划项目按容量搜索，结果混入其他容量的记录
Excel 第 19 行 · 新能源并网五区（xnybw5）
严重性：一般
状态：2.1.待开发
五区
1基本信息
| 问题描述 | 关联规划项目对项目容量进行搜索，搜索的结果不正确（带有其他容量的结果） |
|---|---|
| 一级模块 | 项目信息填报 |
| 二级模块 | /（关联规划项目弹窗） |
| 涉及类型 | 全部类型 |
| 严重性 | 一般 |
| 当前状态 | 2.1.待开发 |
| 研发处理人员 | 陈键泽 |
| 复测情况 | 暂无（待开发中） |
2问题截图
3旧代码涉及的项目文件名及对应行数（backup730 / 730backup）
前端：xnybw5f / src/views/projectNew/components/baseInfo/dialog/planRelationSelector.vue（第 39-41 行，第 438 行）
“关联规划项目”弹窗的“项目容量”搜索输入框绑定
searchForm.capacityKw，原样透传给后端，前端未做任何处理，问题根因不在前端。后端：xnybw5b / src/main/java/cn/csg/so/oms/in/newenergy/project/appservice/NePcPspNewGridApplicationAppService.java（第 46-90 行 getApplicationDataList 方法）
将 capacityKw 参数透传进 MyBatis 查询 Map，未做任何数值规整。
后端 SQL：xnybw5b / src/main/resources/cn/csg/so/oms/in/energy/project/dbconfig/NePcPspGridAppSQL_mysql.xml（第 85-87 行、第 129-131 行，NePcPspGridAppSQL_dm.xml 同名位置同样存在）
<if test="capacityKw!=null and capacityKw!=''"> and CAPACITY_KW like concat('%', #{capacityKw}, '%') </if>
4修复代码涉及的项目文件名及行数
NePcPspGridAppSQL_mysql.xml中NePcPspGridAppVO_selectApplicationPage（约第 61-104 行）与NePcPspGridAppVO_selectApplicationCount（约第 107-139 行）两处的 CAPACITY_KW 过滤条件NePcPspGridAppSQL_dm.xml中对应的达梦版本 SQL（结构与 mysql 版本一致，需同步改）
5修复方案
根因分析：后端对“项目容量”的过滤使用了 LIKE '%容量值%' 的模糊匹配方式作用在一个数值列（CAPACITY_KW）上。数据库执行 LIKE 时会把 DECIMAL 数值先转成字符串再做子串匹配，而字段以 4 位小数存储，例如容量 1.1MW 存储后其字符串形式为 1.1000、容量 3.1MW 为 3.1000——这两个字符串里恰好都含有连续子串 "100"。所以用户搜索“100”时，SQL 引擎不仅会命中真正的 100MW 项目，还会把小数格式化后偶然包含“100”子串的 1.1MW、3.1MW 等完全不相关的项目一并搜出来，这正是截图中出现“容量对不上”记录的原因。这是一种对数值字段做模糊字符串匹配导致的经典误匹配问题，与容量单位无关，任何以特定小数精度存储的数值都可能触发。
修改前（NePcPspGridAppSQL_mysql.xml）
<if test="capacityKw!=null and capacityKw!=''">
and CAPACITY_KW like concat('%', #{capacityKw}, '%')
</if>修改后（建议）
<if test="capacityKw!=null and capacityKw!=''">
and FLOOR(CAPACITY_KW) = CAST(#{capacityKw} AS SIGNED)
</if>由于前端“项目容量”输入框本身已通过 oninput="value=value.replace(/\D/g,'')" 限制只能输入整数（不能输小数点），可以判断该搜索框的产品意图就是按“整数容量”做精确/取整匹配，而不是模糊搜索，因此改为 FLOOR(CAPACITY_KW) = 整数值 的精确比较即可，不需要前端改动。达梦版本 NePcPspGridAppSQL_dm.xml 需要同步替换为等价写法（达梦可用 TRUNC(CAPACITY_KW) = #{capacityKw}）。
同时建议：MyBatis 层的
selectApplicationPage 与 selectApplicationCount 两处 SQL 内容几乎完全一致（复制粘贴出来的两份），本次修复需要两处都改，避免只改列表不改总数导致分页总数与实际列表再次对不上。