之前2.x的时候我就在用 __dirname获取，后面3.x直接删减了nodejs，就不能用了，最好直接用字符串常量前缀
个人看法，资源分级结构为ab包为一级分类，二级分类以资源类型做区分。
按功能模块划分资源，虽然保持了功能之间的独立性，但是有以下几个缺点:
1、资源的查找、修改（压缩）、替换，定位时特别困难，必须对功能了解才能定位。
2、相对路径还带来了重构脚本时的负担
3、不利于资源复用
我个人意见
1，定位，如果不是楼主的结构，你是怎么定位的？是不是一个texture文件夹内放在和模块脚本相同的文件夹内？这样修改时跳来跳去，反而你说的这些都是独立模块解决的问题
2，请详细说明下什么负担，如果只是文件夹路径变更那基本和分资源类型放置时花费的操作是一致的
3，不利于重复利用？单独的texture文件夹重复的资源放在同一文件夹难道单独模块就不能了吗？
我只能说我用了几年的这种资源分类放置的模式，一问主程和技术负责人，就说一直都是这样的，从来不去想想怎么优化和为什么这样做，之前2.x必须这样做我记得好像是打包有问题
每个 ab 包下都是 Res 的结构，每个包保持统一格式。
本质我倾向的是 Res 下具体资源类别区分 A、B、C 功能。
你说的是 A B C 功能模块下，各自有 Res 的区别，区别不是很大，看你喜欢了。
个人还是更喜欢前者。
如果要分包，区别也不大。
想问问你是怎么判断可移植性的？
你可能没理解我说的话，我的意思是和楼主一样，每个模块的资源都放在模块文件夹下，而不是以 bundle 为单位，功能模块下又有功能模块。比如一个子游戏模块下又有登录模块，个人信息模块… 等等，而不只是你说的只放在一个根功能模块下，你这样和分资源类型放置没什么区别
假设 A 模块下有自动图集 AA1, B 模块下有自动图集 AA2，如果在某些情况下做 DrawCall 优化需要将 2 张图合并起来（比如经常通过 A 界面打开 B 界面），合并后的自动图集你归属于谁？
而统一的资源管理，是能够新建一个 AB 文件夹，将 A、B 两个自动图集放进去。
而这种优化，其实还是不少的，资源从逻辑意义上是一定归属某个模块，但是它的物理位置可能是需要根据需求进行调整的。
这种需求是没法做到，但是我做了几年开发也没见过为了不打断dc将两个界面图放在一起的需求，而且就算打断了，新打开的界面也是在最顶层，那么最多加 1 dc，所以权衡利弊，需求少，代价小，换来的是开发的便利性，我觉得很值
噢对了，是可以做到的，但是需要在AB模块的上级模块建立一个自动图集， 然后AB不建立自动图集就行，但是如果需要 AB CD 分别建立两个图集就不行了
分 bundle 的方式，对于规模较大的业务模块是非常 OK 的~
但是对于规模小、零碎的，又希望独立复用的模块来说（例如上面的 SoundButton，就 3 个文件），如果每个模块都拆分成 ab 包，那就是没有可操作性了
跟你的想法一样，一个目录 = 一个模块，但是希望粒度更细
1赞
我的个人感受就是平常维护，做界面这些，经常在资源管理器跳来跳去，项目大了文件多更是麻烦，如果放一块，省事儿省时间，看来楼主和我的想法还是不完全一致
哈哈哈，其实是一致的，非常理解你的意思。
因为我也是，宁可不要图集，也不愿意养一个庞大的【公共资源目录】。
更希望把项目拆成若干的小模块，各自有各自的资源依赖。
复用组件时，把 文件夹 Copy 走就完事。
我们的项目结构形如：
|- frameworks 框架层（经常跨项目复用）
|- prefabs
|- XXX 框架层的组件 经常跨项目复用
|- spriteFrames 这个组件的内部资源
|- 模块 A
|- prefabs 模块 A 的内部资源
|- spriteFrames 模块 A 的内部资源
|- 大模块 B
|- ...
|- scenes 业务层 场景
|- 场景 1
|- spriteFrame 场景 1 的内部资源
|- ...
|- prefabs 业务层 全局复用的 Prefab
|- scripts 业务层 全局复用的脚本
|- spriteFrames 业务层 全局复用的 SpriteFrame
模块化和组件化是以文件夹为单位的，但文件夹不一定是 bundle，因为粒度可能很细。
也正因为如此，对相对路径引用非常刚需。
图集的问题，我们正尝试通过插件解决，例如开发时刻不通过目录划分图集，而是另写一个配置文件，去规划图集及其引用的资源目录范围。
别人不是想在编辑器加载
哦哦,那可以在编辑器添加组件到节点上的时候自动设置,序列化后在运行的时候也可以获取.
？那如果我改变文件夹结构岂不是要修改所有影响的预制体?