SQLite group_concat 的顺序：查询末尾已经排序，拼接内容为何还可能乱
把几个工序拼成一段路径，查询最外层写了 ORDER BY，字符串里的工序却未必按照它排列。最外层排序安排的是已经产生的结果行；要规定 group_concat 逐个接收值的次序，应把 ORDER BY 写在聚合函数最后一个参数之后。
这项语法从 SQLite 3.44.0 开始支持。下面保存为 demo.mjs，用 Node.js 24 的 node demo.mjs 运行；代码检查实际内置SQLite版本，再创建内存表。所有删除仅针对刚创建的演示表，连接关闭后数据消失。
AI模型生成概念示意：分散的项目先按规则排列，再连成一个整体；不是SQL执行计划或真实界面。
import assert from 'node:assert/strict';
import { DatabaseSync } from 'node:sqlite';
const db = new DatabaseSync(':memory:');
try {
const version = db.prepare('SELECT sqlite_version() AS v').get().v;
const [major, minor] = version.split('.').map(Number);
assert.ok(major > 3 || (major === 3 && minor >= 44));
db.exec('CREATE TABLE step(id INTEGER PRIMARY KEY, seq INTEGER, label TEXT)');
const insert = db.prepare('INSERT INTO step VALUES (?, ?, ?)');
const input = [[30, 2, 'polish'], [10, 1, 'cut'],
[20, 2, 'fit'], [40, 3, null]];
const query = db.prepare(`
SELECT group_concat(label, ' > ' ORDER BY seq, id) AS path,
group_concat(label, ' > ' ORDER BY seq DESC, id DESC) AS reverse_path
FROM step
`);
for (const row of input) insert.run(...row);
const result = query.get();
assert.equal(result.path, 'cut > fit > polish');
assert.equal(result.reverse_path, 'polish > fit > cut');
console.log('ascending: ' + result.path);
console.log('descending: ' + result.reverse_path);
db.exec('DELETE FROM step');
for (const row of [...input].reverse()) insert.run(...row);
assert.deepEqual(query.get(), result);
console.log('reversed insertion: same ordered results');
db.exec('DELETE FROM step');
assert.equal(query.get().path, null);
console.log('empty input: null');
} finally {
db.close();
}把顺序放在消费这些值的函数里
前两行输出 ascending: cut > fit > polish 与 descending: polish > fit > cut。同一次聚合查询产生两种相反的拼接次序，因为两个函数各自拥有输入排序规则。这里不需要先把整张结果表倒排，再期待某个聚合函数碰巧沿那个顺序读到值。
seq 为二的工序有两个，所以只按 seq 排序还不足以规定谁先出现。示例再加入唯一的 id 作为并列时的次序，并在降序版本中同时反转两个键。真实业务的并列规则可能是创建时间或明确的步骤编号，应该按需求选，不能把唯一编号天然当作发生顺序。
乱序插入与空值都要实测
代码清空演示表后把输入反着插入，再比较两列结果，得到 reversed insertion: same ordered results。这条断言检验的是明确写出的排序承诺。未写内部排序时，即便几次运行的结果一致，也不能据此推定未来的索引或查询计划变化不会影响它。
编号四十的 label 是 NULL，未进入任何拼接，也没有贡献额外分隔符。全部记录删去后，输出 empty input: null，说明空输入的结果并不是空字符串。若页面需要显示空白，可以在展示层处理，但应保留数据层“没有可拼值”的含义。
拼接结果是否还能拆回来，要另外约定
本例标签都不包含分隔符，因此输出适合阅读。如果标签自身能够出现大于号或所选分隔文本，结果不能直接靠 split 稳定恢复原数组。需要可靠往返时，可使用结构化数组形式，并为对应聚合函数同样指定输入顺序。排序确定不代表序列化格式没有歧义。
大分组还要考虑拼接长度与排序成本，不能因为最后只返回一行就认定查询轻量。接入旧数据库时，先检查连接实际使用的SQLite版本；操作系统里另一个命令行工具的版本，不能证明应用内置库支持同样语法。
资料核对日期：2026年10月2日。完整代码在 Node.js v24.19.0、内置 SQLite 3.53.3 实跑，两个排序方向及反向插入、空输入断言全部通过。
