做音乐播放器的时候，播放列表的数据持久化几乎是绕不开的一环。本地JSON文件虽然写起来快，但一旦用户建了十几个列表、每个列表几百首歌，增删改查的性能和并发问题就会暴露出来。SQLite作为一个零配置的嵌入式数据库，天然适合这类桌面或移动端应用，本文就从表结构设计讲起，完整走一遍播放列表管理的实现流程。
一、表结构设计：三张表撑起整个播放列表
播放列表管理的核心难点在于：一个列表包含多首歌，一首歌也可以出现在多个列表里，这是典型的多对多关系。如果只用一张表硬塞，后续维护会非常痛苦。推荐拆成三张表来设计。
歌曲表t_song负责存放歌曲的元信息，比如标题、艺术家、专辑、文件路径、时长等。这些信息只存一份，无论这首歌被加入多少个播放列表，磁盘路径都不会重复占用存储。
播放列表表t_playlist存放列表本身的信息，包括列表名称、创建时间、封面等。注意列表名最好加唯一约束，避免用户创建出两个同名的列表导致自己都分不清。
第三张是关联表t_playlist_item，它是整个设计的枢纽。除了列表ID和歌曲ID两个外键之外，还需要一个position字段记录歌曲在列表中的顺序。建表SQL如下：
CREATE TABLE t_song (
song_id INTEGER PRIMARY KEY AUTOINCREMENT,
title TEXT NOT NULL,
artist TEXT DEFAULT '未知艺术家',
album TEXT DEFAULT '未知专辑',
file_path TEXT NOT NULL UNIQUE,
duration INTEGER DEFAULT 0, -- 时长，单位毫秒
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE t_playlist (
playlist_id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL UNIQUE,
cover_path TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE t_playlist_item (
item_id INTEGER PRIMARY KEY AUTOINCREMENT,
playlist_id INTEGER NOT NULL,
song_id INTEGER NOT NULL,
position INTEGER NOT NULL,
added_at DATETIME DEFAULT CURRENT_TIMESTAMP,
UNIQUE(playlist_id, song_id), -- 同一列表内歌曲不重复
FOREIGN KEY (playlist_id) REFERENCES t_playlist(playlist_id) ON DELETE CASCADE,
FOREIGN KEY (song_id) REFERENCES t_song(song_id) ON DELETE CASCADE
);
这里有两个细节值得注意。第一，UNIQUE(playlist_id, song_id)这个联合唯一约束可以防止用户把同一首歌重复添加到同一个列表，插入时如果违反约束，SQLite会抛出异常，应用层捕获后提示用户即可，比在代码里先查询再插入要可靠得多。第二，外键的ON DELETE CASCADE表示删除播放列表时，关联表里的记录会自动清理，不需要手动执行两次删除。不过要注意，SQLite默认不开启外键支持，每次建立连接后必须先执行PRAGMA foreign_keys = ON;，否则级联删除不会生效。
另外建议给position建一个复合索引CREATE INDEX idx_item_pos ON t_playlist_item(playlist_id, position);，因为查询列表内容时几乎总是按列表ID过滤再按位置排序，这个索引能让排序直接走索引完成。
二、增删改查：顺序字段是重中之重
添加歌曲到列表末尾
添加歌曲时，position的取值应该是当前列表最大位置加一。可以先查出最大值再插入：
INSERT INTO t_playlist_item (playlist_id, song_id, position) SELECT 5, 102, IFNULL(MAX(position), 0) + 1 FROM t_playlist_item WHERE playlist_id = 5;
这条SQL把“查最大值”和“插入”合并成一条语句，借助IFNULL处理空列表的情况，避免了应用层两次往返数据库。如果一次要添加多首歌，务必用事务把所有插入包起来，既能保证position连续，性能也比逐条提交好一个量级。
从列表中移除歌曲
删除歌曲后，被删位置后面的歌曲position会出现空洞。有两种处理策略：一是删除后立刻把后面的记录整体前移：
-- 先删除指定歌曲 DELETE FROM t_playlist_item WHERE playlist_id = 5 AND song_id = 102; -- 把后面所有歌曲的位置前移一位 UPDATE t_playlist_item SET position = position - 1 WHERE playlist_id = 5 AND position > 3; -- 3是被删歌曲原来的位置
二是干脆不整理，留着空洞，反正展示时是按position升序排，空洞不影响顺序。两种方案各有取舍：立即整理的好处是position始终连续，取“第N首歌”很方便；不整理的好处是减少写操作，适合频繁删除的场景。如果选择后者，可以在合适的时机（比如应用退出前）做一次整体重编号。
拖拽排序的实现
现代播放器基本都支持拖拽调整歌曲顺序。假设用户把第10首歌拖到第3的位置，最直观的做法是把position从3到9的歌曲依次加一，再把目标歌曲设为3。如果拖拽涉及的范围较大，一条UPDATE配合BETWEEN就能完成：
-- 将歌单5中position为10的歌曲移动到position为3的位置
UPDATE t_playlist_item
SET position = CASE
WHEN position = 10 THEN 3
ELSE position + 1
END
WHERE playlist_id = 5
AND position BETWEEN 3 AND 10;
注意这个操作必须包在事务里，否则中途失败会导致顺序错乱。一个更优雅的替代方案是position不用连续整数，改用浮点数或间隔较大的整数（比如每次加1000），移动一首歌时只需要取前后两首歌position的中间值即可，一次UPDATE搞定，完全避开批量更新。等间隔耗尽时再统一重排一次。
查询播放列表内容
查询时关联歌曲表，取出完整信息并附带序号：
SELECT i.position, s.song_id, s.title, s.artist, s.duration, s.file_path FROM t_playlist_item i JOIN t_song s ON s.song_id = i.song_id WHERE i.playlist_id = 5 ORDER BY i.position ASC;
如果列表里歌曲很多，前端采用分页或懒加载，可以在查询末尾加上LIMIT和OFFSET。
三、进阶技巧：事务、并发与性能优化
批量操作一定要用事务。SQLite默认每个INSERT都是独立事务，都会触发一次磁盘同步，往列表里批量导入500首歌可能要好几秒；包在BEGIN和COMMIT之间后只需一次同步，通常几十毫秒就能完成。以Python为例：
import sqlite3
def add_songs(conn, playlist_id, song_ids):
cur = conn.cursor()
try:
cur.execute("BEGIN")
for sid in song_ids:
cur.execute(
"""INSERT INTO t_playlist_item (playlist_id, song_id, position)
SELECT ?, ?, IFNULL(MAX(position), 0) + 1
FROM t_playlist_item WHERE playlist_id = ?""",
(playlist_id, sid, playlist_id)
)
conn.commit()
except Exception:
conn.rollback()
raise
并发方面，SQLite采用库级锁，多个线程同时写会碰到database is locked错误。在播放器这种场景下，建议把数据库操作收敛到单一队列或单一线程中执行，或者打开WAL模式：PRAGMA journal_mode = WAL;。WAL模式允许读写并行，播放线程读列表的同时，后台扫描线程可以继续写入新歌曲，体验会顺畅很多。
性能上还有几个容易忽略的点。第一，歌曲库的全量扫描入库属于典型的批量写入，除了事务外还可以临时关闭同步检查PRAGMA synchronous = OFF;，导入完再恢复。第二，搜索功能建议给t_song的title和artist字段建索引，或者使用SQLite的FTS5全文检索扩展，中文搜索可以用简单的二元分词配合FTS5的tokenize参数处理。第三，数据库文件要放在用户数据目录而不是程序安装目录，否则升级或权限变化时容易出问题。
最后提一句备份：SQLite的数据库文件是单文件，直接复制.db文件即可完成备份，但要在没有写入事务进行时复制才安全，或者使用官方提供的sqlite3_backup在线备份接口。播放器的歌单数据对用户来说价值不低，做好定期备份能省去不少麻烦。
总结一下，三表结构理清多对多关系，position字段配合事务处理排序，再用WAL模式和索引兜底性能，这套方案足以支撑一个功能完善的音乐播放器。剩下的就是根据产品需求，在播放历史、收藏、智能歌单等功能上继续扩展表结构即可。