无限队列管理是一种围绕可无限延伸播放队列的状态设计方式。队列起初是一个有限列表（如专辑或播放列表），当来源的续接内容耗尽且开启“继续播放”设置时，应用会从最后一首曲目推导出后续来源，并向同一队列追加内容。由此队列状态产生两种写入，且二者不能合并为同一函数。
路径一为 setter，用于新队列：替换数据并重新计算由其派生的快照。示例中 setQueueData 更新 _queueData 的 data，并在播放列表类型为专辑时，把专辑曲目 id 集合写入 player.albumTrackIds，否则置为空集。
路径二为追加，用于同一队列变长：直接更新 _queueData 调用 addTrackList 写入新页，不触碰派生快照。这种非对称是刻意的：albumTrackIds 用于回答“两首曲目是否来自同一专辑”，供转场效果在专辑内部让位、在专辑边缘恢复。自动追加的曲目并不属于该专辑，边界正是效果应当恢复的位置。若把追加走 setter，这些曲目会被并入集合，导致整个队列的特性失效；在追加时重算快照也会逐页造成同样结果。
文中列出若干陷阱。其一，非对称在追加处不可见：_queueData.update { it.addTrackList(page) } 看起来像普通状态写入，后来者可能合并两条路径且测试仍通过，但派生特性会静默失效；因此要在 setter 与追加两端都写注释，说明原因和破坏了什么。其二，合并前先 grep，检查 _queueData.update、_queueData.value、setQueueData( 的调用点，并只读 setter 函数体；若它触碰 flow 之外的任何东西，两路径就不可互换。其三，快照必须是 id 集合，不能是数量或范围，因为随机播放会重排整个队列；成员判断须对转场涉及的两首曲目都成立：currentId in player.albumTrackIds && nextId in player.albumTrackIds。其四，给重新播种加保护，否则队列会无限追加：从最后一首曲目推导后续来源 id，并与队列当前来源 id 比较，相同则返回；不要用“已扩展”布尔标志，因为它无法区分第二次合法扩展与第一次重复。其五，派生快照不跨进程重启存活：快照在加载时计算，恢复路径可能不携带来源类型，若持久化队列行没有该列，恢复会回退到通用类型，快照为空，表现为会话内正常、重启后失效；应持久化判别字段，或在恢复代码旁记录限制。其六，改变来源 id 的追加仍是追加：替换 playlistId 是现有队列上的元数据变更，应走直接写入路径，走 setter 会重置快照，正是该拆分要避免的缺陷。其七，数据类的 update {} 不等同于构造新状态：追加辅助函数应返回接收者的副本；若返回填充列表的默认副本，会静默丢弃来源 id 与续接令牌，稍后表现为队列拒绝加载更多。
验证方式：开启自动扩展播放一张专辑到结束，依次检查队列是否超出专辑曲目数、派生快照是否仍恰好包含专辑 id（记录其大小，队列增长时不应变化）、以及受该特性控制的行为在最后一张专辑边界与两首专辑曲目之间是否不同。若快照大小随队列增长，说明某次追加走了 setter。