Nopcommerce中Roxy Fileman删除PDF文件触发JS报错如何修复

前置干扰项排查 #

先排除控制台无关日志的干扰，避免误导排查方向：

• 静态资源source map 404报错：属于浏览器加载调试映射文件失败，不影响生产环境脚本运行，可在开发者工具设置中临时关闭Enable JavaScript source maps屏蔽这类日志
• jquery-migrate加载提示、编辑器插件加载提示：只要不是标红的error级日志，均为兼容/加载类非阻断告警，和文件删除逻辑无直接调用链路，暂不纳入排查范围

已知文件夹删除功能正常，可直接判定：后端删除接口、权限校验、通用请求发送逻辑无问题，故障点100%集中在Main.js中deleteFile()函数的单文件删除专属分支逻辑

核心缺陷排查方向（按出现概率排序） #

1. 图片专属逻辑缺少类型兜底（最高发）
   绝大多数二次修改的Roxy Fileman版本会给图片类文件增加缩略图缓存清理、预览DOM移除的逻辑，但没有加文件类型判断：删除PDF、压缩包等非图片文件时，代码尝试读取不存在的thumbUrl属性、查找不存在的预览DOM节点，直接触发Cannot read property of undefined类JS错误。而文件夹删除走独立的递归删除分支，不会触发单文件缩略图处理逻辑，因此运行正常。
   修复参考：在所有图片专属操作前增加类型判断，对非图片文件跳过对应逻辑：

   function deleteFile() {
       const selectedItem = getSelectedFile();
       if (!selectedItem) return false;
   
       // 仅图片类型执行缩略图、预览节点清理逻辑
       if (selectedItem.fileType === 'image') {
           const previewNode = document.querySelector(`[data-preview-path="${selectedItem.fullPath}"]`);
           // 增加节点存在性判断，避免空节点操作报错
           if (previewNode) previewNode.remove();
           clearThumbCache(selectedItem.path);
       }
   
       // 保留原有通用删除请求、列表刷新逻辑，和文件夹删除分支复用同套参数处理规则
       $.post('/fileman/delete', {
           path: encodeURIComponent(selectedItem.fullPath)
       }, (res) => refreshFileList())
   }
   

2. 文件路径编码规则不一致
   检查文件夹删除和单文件删除的参数处理逻辑：如果文件夹删除分支对路径做了encodeURIComponent转义，但单文件分支没做，删除带空格、中文、特殊字符（如括号、百分号）的PDF文件时，会出现请求参数解析异常，后续回调函数拿不到合法返回值触发报错。
   修复方式：对齐两个分支的路径编码规则，不要分别维护两套参数处理逻辑。
3. 删除回调的组件初始化判断缺失
   检查删除成功后的回调逻辑：部分版本会在回调中强制刷新图片懒加载、图片预览组件实例，如果当前删除的是非图片文件，对应组件根本没有初始化，直接调用实例方法会触发报错。
   修复方式：在调用组件方法前，先判断实例是否存在，再执行对应刷新操作。

快速验证方法 #

• 在deleteFile()函数第一行加debugger断点，单步执行代码，直接定位抛出异常的具体代码行，无需盲查源码
• 分别测试删除图片、TXT、ZIP、PDF格式文件，确认是否仅非图片文件触发报错，验证图片逻辑兜底缺失的猜想
• 对比官方原生同版本Roxy Fileman的deleteFile()函数逻辑，排查NopCommerce集成时的二次修改点是否遗漏分支判断

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