Files
Harmon 5a0623fd9b refactor(frontend): canonicalize active panel files
- replace rewrite/clean transitional panel files with canonical filenames

- update imports and navigation architecture notes to match runtime truth

- ignore local .codex_tmp workspace artifacts
2026-04-27 08:05:10 +08:00

4.1 KiB

INIT

说明:本文件是开发/运维工作笔记,不是当前系统架构、部署或运行事实的最高依据。
优先阅读 README.mddocs/INDEX.mddocs/DOCUMENTATION_GOVERNANCE.md

1. 当前开发机已确认的本机环境

  • Windows 开发机 Python 解释器:C:\ProgramData\anaconda3\envs\InSAR\python.exe
  • 当前项目运行时应优先从 .env 读取路径,不允许在代码中写死开发机盘符或目录。
  • 与 D-InSAR / ISCE2 / WSL 相关的运行目录、输出目录、轨道目录、DEM 路径都应通过 .env 配置维护。

2. 本轮已落地的修复

2.1 D-InSAR 生产与产物任务日志管理

  • 后端新增任务运行日志专用路由:
    • backend/app/routers/tasks_runtime.py
  • backend/app/routers/tasks.py 改为兼容导出入口。
  • backend/app/services/task_service.py 新增:
    • 单条任务日志删除
    • 当前任务日志清空
  • 前端已接入:
    • frontend/src/api/tasks.js
    • frontend/src/DinsarProductionPanel.jsx
    • frontend/src/DinsarProductsPanel.jsx

当前已支持:

  • 查看任务日志
  • 删除单条任务日志
  • 清空当前任务全部日志

2.2 D-InSAR 提交链路与运行时问题

  • 修复 backend/app/services/job_handlers.py 中缺失 datetime 导入导致的控制器异常。
  • 修复 D-InSAR 运行时目录处理逻辑,避免继续依赖历史开发机 Z:\ 路径。
  • 当前原则:路径统一走 .env,不允许把开发机专用盘符写入跟踪代码。

2.3 前端编码与临时文件收口

本轮已清理以下面板中的残留乱码与混杂英文:

  • frontend/src/DinsarProductionPanel.jsx
  • frontend/src/DinsarProductsPanel.jsx

此前前端存在一批过渡文件名,例如:

  • *.rewrite.jsx
  • LogManagementPanel.clean.jsx

这些文件名现在已经完成收口,当前应以正式文件名作为事实来源:

  • frontend/src/DinsarProductsPanel.jsx
  • frontend/src/components/DinsarCatalogPanel.jsx
  • frontend/src/panels/DinsarResultPanel.jsx
  • frontend/src/components/ResultExportModal.jsx
  • frontend/src/components/panels/DinsarResultRow.jsx
  • frontend/src/LogManagementPanel.jsx

当前原则:

  • 不再让“rewrite / clean”文件名长期停留在主分支
  • 当前被界面实际使用的实现,应恢复为正式文件名
  • 如后续再次出现临时过渡文件,必须在功能稳定后尽快收口

3. PowerShell 使用注意事项

3.1 查看中文文件时

Windows PowerShell 5.x 下,终端读取 UTF-8 中文文件时可能出现乱码,这不一定代表源码文件本身已坏。

推荐先执行:

chcp 65001
$OutputEncoding = [Console]::OutputEncoding = New-Object System.Text.UTF8Encoding($false)

如果仍然显示异常,优先用编辑器直接查看源码,不要仅凭 PowerShell 控制台输出判断文件编码是否损坏。

3.2 写入源码文件时

Windows PowerShell 5.x 的 Set-Content -Encoding UTF8 默认会写入 BOM。对脚本、配置或前端源码,BOM 可能继续引出兼容问题。

因此本项目内不建议直接用这类命令覆盖源码文件。更稳妥的方式:

  • 优先使用编辑器或补丁方式修改源码
  • 如果必须在 PowerShell 中写文件,使用无 BOM UTF-8

示例:

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllText("D:\Code\Insar_management_system_v2\somefile.txt", $content, $utf8NoBom)

4. WSL / ISCE2 相关约束

  • 当前项目已经按“Windows 业务登记 + WSL 执行 ISCE2”模式接入。
  • 是否继续维持双环境桥接,只能作为 fallback 方案讨论;默认正式链路仍应以单一、可维护、可配置的环境为主。
  • 后续若继续收敛环境,优先原则是:
    • 先保证正式生产链稳定
    • 再讨论实验期环境是否下线
    • 所有环境差异都必须记录到文档,不能只留在口头结论里

5. 本轮验证结果

  • 前端已重新执行 npm run build,构建通过。
  • 当前界面实际已恢复以下中文区域:
    • 日志管理
    • 运行监控
    • 处理模板
    • D-InSAR 产物说明文案