CROSS JOIN 本身不生成新数据，仅做笛卡尔积；要生成连续日期序列，必须先用递归CTE或GENERATE_SERIES等构造数字/日期源，再与其他表关联。
为什么 CROSS JOIN 不能直接生成日期序列
CROSS JOIN 本身不生成新数据，它只是把两个表的每一行做笛卡尔积。想生成日期序列，必须有一个能产生连续数字或日期的“源表”，否则 CROSS JOIN 没东西可连——常见错误是写 SELECT * FROM (SELECT '2024-01-01') t1 CROSS JOIN (SELECT '2024-01-02') t2，结果只得到两行固定值，不是“从起始到结束的所有日期”。
用递归 CTE + CROSS JOIN 构造日期范围（推荐）
多数现代 SQL 引擎（PostgreSQL、SQL Server、SQLite 3.38+、MySQL 8.0+）支持递归 CTE，这是最可控的方式。关键不是靠 CROSS JOIN 生成日期，而是先用递归生成整数序列，再转为日期，最后按需 CROSS JOIN 其他表。
例如：生成 2024-01-01 到 2024-01-10 的所有日期，并与用户表关联：
WITH RECURSIVE dates AS ( SELECT DATE '2024-01-01' AS dt UNION ALL SELECT dt + INTERVAL '1 day' FROM dates WHERE dt
-
RECURSIVE是必需关键字，漏写会报错（如 PostgreSQL 报recursive query "dates" does not have a recursive term） - 日期加法语法因数据库而异：
dt + INTERVAL '1 day'（PostgreSQL）、DATEADD(day, 1, dt)（SQL Server）、dt + 1（MySQL，仅对DATE类型有效） - 递归深度默认有限制（如 PostgreSQL 默认 100），超限时需加
MAXRECURSION（SQL Server）或SET max_recursive_iteration = N（MySQL）
用系统表/生成器表替代递归（兼容老版本）
在不支持递归 CTE 的环境（如旧版 MySQL 或某些嵌入式 SQLite），可借助已有行数足够的系统表（如 information_schema.columns）或手动构造数字表，再用 CROSS JOIN 配合 ROW_NUMBER() 或日期运算。
例如（PostgreSQL）：
SELECT '2024-01-01'::DATE + (n - 1) * INTERVAL '1 day' AS dt FROM ( SELECT ROW_NUMBER() OVER() AS n FROM pg_catalog.pg_class LIMIT 10 ) nums;
- 依赖
pg_class行数 ≥ 所需天数；若不确定，可用generate_series(1, 10)（PostgreSQL 原生函数，比CROSS JOIN更直接） - MySQL 5.7 可用
(SELECT 1 UNION SELECT 2 UNION ...)手动拼数字，但超过几十天就不可维护 - 这种写法本质是“借表凑行数”，不是真正意义上的
CROSS JOIN生成逻辑，容易在表被清空或权限受限时失败
CROSS JOIN 后日期字段没对齐？检查隐式类型转换
当 CROSS JOIN 结果里日期显示为 1970-01-01 或全为 NULL，大概率是日期计算中混入了非 DATE 类型（如字符串、整数）。不同数据库对 '2024-01-01' + 1 的解释完全不同：
- PostgreSQL：报错（类型不匹配）
- MySQL：把字符串转成数字再加，
'2024-01-01' + 1 → 2024，再转成日期变成1970-01-01 - SQL Server：尝试隐式转成
DATETIME，但若格式不对（如'2024/01/01'在某些语言设置下失败）
务必显式转换：CAST('2024-01-01' AS DATE) 或 TO_DATE('2024-01-01', 'YYYY-MM-DD')，别依赖自动推导。
生成日期序列这事，核心不在 CROSS JOIN 本身，而在你拿什么去跟它叉。递归 CTE 最稳，系统表凑数最险，而所有踩坑点，几乎都出在日期类型的那一层薄薄的隐式转换上。
