Batocera ROM资源分区管理：不是“放对文件夹就行”，而是Linux存储工程的精密编排
你有没有试过把几百个PS2 ISO拷进/userdata/roms/ps2/，重启后EmulationStation却只显示37个游戏？或者某天插上USB硬盘，系统直接卡在启动画面——不是死机，是卡在mount: /userdata: wrong fs type那一行？又或者明明ROM都在，但一进游戏就报错“BIOS not found”，翻遍/userdata/bios/却发现那个SCPH1001.BIN明明就在那里？
这不是你的ROM坏了，也不是模拟器抽风。这是Batocera底层存储治理逻辑在向你发出信号：它不接受“差不多就行”的文件摆放，只响应精确、可审计、有契约的分区行为。
本文不讲“如何把ROM拖进去就能玩”，而是带你钻进/usr/bin/batocera-system的shell脚本里，扒开/etc/fstab的挂载参数，对照platform_ids.csv逐行验证ID映射，最后站在systemd服务图谱上，看清一次“选择ROM位置”操作背后触发的17个子进程链。这不是教程，是一份给系统集成者、ROM仓库运维人、以及不愿再被“莫名不识别”折磨的硬核玩家的技术解剖报告。
为什么/userdata/roms/nes/不能叫/userdata/roms/NES/？——从VFS到EmulationStation的路径契约
Batocera前端EmulationStation根本不认大小写，它认的是es_systems.cfg里写的<platform>nes</platform>，而这个nes又来自platform_ids.csv里的第一列。你改一个目录名，等于撕毁一份三方合约：
-platform_ids.csv说：“nes→ 中文‘红白机’ → 图标/usr/share/batocera/resources/platforms/nes.svg”；
-es_systems.cfg说：“<platform>nes</platform>的路径是/userdata/roms/nes/，支持.nes .zip .7z”；
-configgen.py说：“我每开机都按CSV重生成一遍es_systems.cfg，你别手改”。
所以当你建了NES/目录，EmulationStation扫描时发现：
✅ 有/userdata/roms/NES/这个路径；
❌ 但es_systems.cfg里没有<platform>NES</platform>；
