sqlite触发器内无法调用自定义c函数，因其执行环境隔离于c函数注册表，仅支持内置sql函数（如current_timestamp、coalesce()等）、聚合函数和raise()；自定义函数如json_validate()在触发器中调用会报“no such function”错误。
SQLite不支持自定义聚合函数的直接注册
SQLite原生不提供类似PostgreSQL的CREATE AGGREGATE或MySQL的UDF机制，无法像在服务端数据库那样动态注册C语言编写的自定义聚合函数（如median()、mode()）。你看到的count()、sum()、avg()等，都是SQLite内建的硬编码函数，不能通过SQL语句扩展。如果项目里有storage.select(custom_agg(&T::field))这类写法，那实际是sqlite_orm库在C++层做了封装，并非SQLite本身能力。
用内置聚合 + 表达式模拟简单自定义逻辑
对轻量级数学变换（比如“每组工资加10%再取整”），可直接在SELECT中组合内置函数与算术表达式，无需真正“自定义”：
-
ROUND(AVG(salary) * 1.1, 2)：先算平均值，再乘1.1并保留两位小数 -
MAX(salary) - MIN(salary)：计算组内极差，本质是两个聚合函数的组合 -
COUNT(*) * 100.0 / (SELECT COUNT(*) FROM employees)：算百分比，注意分母必须用子查询避免GROUP BY干扰
⚠️ 注意：ROUND()、ABS()、POWER()等标量函数可在聚合结果上使用，但不能对原始列做“先变换再聚合”的嵌套，比如SUM(ROUND(salary * 1.1))是合法的，而SUM(IFNULL(salary, 0) * 1.1)也行——关键是所有运算都得落在聚合函数**内部**或**外部**，不能跨层级混用。
实现中位数、众数等需绕过GROUP BY限制
像中位数（median）、众数（mode）这种依赖排序位置的统计量，SQLite 3.25.0+ 可用窗口函数逼近，但必须放弃纯GROUP BY思路：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 中位数：用
PERCENT_RANK() OVER (PARTITION BY dept ORDER BY salary)找0.5附近值，或用两次ROW_NUMBER()上下逼近 - 众数：必须用
GROUP BY dept, name先计频次，再用FIRST_VALUE(name) OVER (PARTITION BY dept ORDER BY COUNT(*) DESC, name)取首名 - 若版本(SELECT name FROM t2 WHERE t2.dept = t1.dept GROUP BY name ORDER BY COUNT(*) DESC LIMIT 1)
这些方案都不是“在GROUP BY里调用一个自定义函数”，而是用标准语法重构问题——因为SQLite的GROUP BY执行顺序固定：WHERE → GROUP BY → HAVING → SELECT → ORDER BY，中间没有插槽让你塞进任意逻辑。
真正需要复杂聚合时该怎么做
如果你的业务强依赖STDEV()、QUANTILE_CONT()或带状态的流式聚合，SQLite不是合适选型：
- 在应用层聚合：读出分组数据（如
SELECT dept, salary FROM emp GROUP BY dept），用Python/JS/C++做后续计算 - 换用支持扩展的引擎：如DuckDB（支持
median()、quantile()开箱即用）或LiteFS+PostgreSQL嵌入方案 - sqlite_orm用户可利用其C++模板能力封装逻辑，但最终生成的仍是标准SQL，不改变SQLite内核限制
关键点在于：SQLite的聚合能力边界清晰——它擅长高效分组计数和线性计算，不设计用来承载任意数学语义。强行“模拟”只会让SQL变晦涩、难调试、难迁移。
