直接修改 config.json 中 sidebarModules 数组顺序即可调整右侧面板模块顺序，需完全退出并重启应用生效；拖拽无效多因前端未持久化保存；Mac 上应编辑用户目录下的 config.json 而非 .app 内只读副本。
Electron 应用中修改右侧面板模块顺序：直接改 config.json 里的 sidebarModules 数组
主界面右侧面板的模块顺序，绝大多数 electron 桌面应用（比如某内部工具平台、文档协作客户端）靠配置文件驱动，不是靠拖拽实时保存。所谓“拖拽排序”往往只是 ui 反馈，最终仍需写回配置——而很多应用压根没实现拖拽持久化，你松手就还原。
真实路径通常是 resources/app/config.json 或用户目录下的 config.json（如 ~/.myapp/config.json），找含 sidebarModules 或 rightPanelOrder 的数组字段：
{
"sidebarModules": ["project", "issues", "chat", "settings"]
}
- 顺序严格按数组索引，把
"chat"提到"issues"前面，就得手动调换位置 - 删掉某个模块名，对应面板直接不显示；拼错名字（比如写成
"chats"），该模块加载失败且可能报Module not found: chat - 改完必须完全退出进程再重启，热重载通常不刷新 sidebar 配置
Vue / React 前端侧发现拖拽后顺序不生效：检查是否漏了 onDragEnd 回调里的 saveConfig()
如果界面上能拖，松手也动了，但重启就回到原样——八成是前端只改了内存数组，没调用保存逻辑。常见于用 vue-draggable 或 react-beautiful-dnd 实现的面板，但开发者忘了连配置持久化。
重点查两个地方：
- 拖拽结束回调里有没有触发类似
updateSidebarOrder(newOrder)的函数，且该函数内部是否调用了localStorage.setItem('sidebarOrder', JSON.stringify(newOrder))或发 API 到后端 - 组件初始化时，是否从本地存储或接口取值来初始化
sidebarModules，而不是硬编码默认顺序 - 注意 Vue 响应式陷阱：直接赋值数组项（
arr[0] = 'x'）不会触发更新，得用splice或替换整个数组
Mac 上改完配置不生效？确认你编辑的是实际加载的 config.json，不是安装包里的只读副本
macOS 应用常把资源打包进 .app 包内，路径类似 /Applications/MyApp.app/Contents/Resources/app.asar，这种是压缩归档，直接改里面文件无效，甚至会被系统阻止写入。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 先运行
ps aux | grep MyApp看进程启动路径，再用lsof -p [PID] | grep config查它真正读的是哪个config.json - 多数情况是读用户目录下那个（如
~/Library/Application Support/MyApp/config.json），而非.app内部 - 如果真要改 asar 里的默认配置，得先用
asar extract app.asar out_dir解包，改完再asar pack out_dir app.asar，但下次升级会覆盖
Electron 主进程里动态重载 sidebar 配置：别用 require('./config.json')，改用 fs.readFileSync + JSON.parse
如果想让主进程监听配置变化并实时刷新右侧面板（比如配置文件被外部脚本修改），就不能用 require——Node.js 会缓存模块，第二次 require 返回旧内容。
正确做法是在需要时主动读取：
const fs = require('fs');
const configPath = path.join(app.getPath('userData'), 'config.json');
const config = JSON.parse(fs.readFileSync(configPath, 'utf8'));
- 搭配
fs.watch监听文件变更，触发webContents.send('sidebar-updated', config.sidebarModules) - 注意
fs.watch在 macOS 上对文件替换（如编辑器保存机制）可能触发两次事件，加个防抖 - 别在渲染进程用
fetch('/config.json')——开发环境可能走 webpack dev server，生产环境没这个路由
最麻烦的点其实是：不同模块的加载时机和依赖关系藏在代码深处，改顺序后某个模块初始化失败，错误堆栈未必指向配置本身，而是卡在它依赖的另一个模块未就绪。这时候得翻 main.js 里 createWindow 后的模块注册逻辑，看谁先谁后。
