mastodon（或者说gem paperclip）一个恶心的地方是储存媒体文件时要把activity record id拆分成了一大串子目录：如图1的文件，其原本的id是104530971904218116，最后被拆成了104/530/971/904/218/116 （：id_partition部分）
我想不出这样设计有什么意义，但是最终的结果是list对象储存时会产生大量性格最贵的C类请求。misskey是将所有文件储存在根目录，list n个文件产生n次C类请求，这是最理想的情况，但是同样的n个文件mastodon要产生n*(6+2)次C类请求，+2是因为104/530/971/904/218/116 下面还有original和small两个子文件夹。
打算趁这次重构的机会把这个地方改一下，直接把所有内容写在文件名上不就行了：
':prefix_url:class/:attachment/:id_partition/:style/:filename' -> ':prefix_url:class/:attachment/:id-:style-:filename'
@[email protected] COS当存储服务器给我的感觉就是有钱（
似乎在本地文件系统使用的时候这样拆分成树状目录可以稍微提升一点访问速度？（毕竟是在树上搜索
Follow
@xtexChooser 其实cos是是目前相对便宜的解决方案，下载流量我是通过一台内网服务器代理的，实际成本就是每月十来块的储存和请求费用
@xtexChooser 等改了路径以后我是打算用nginx重定向旧文件的
@[email protected] 也许可以试试用caddy或者nginx之类反代一下解决URL问题（x