SQLite没有像PostgreSQL那样内置的GENERATED ALWAYS AS语法，但这并不意味着我们没法实现“计算列”的效果。一个很自然的替代方案就是视图——通过封装SELECT表达式，在查询时动态计算结果。虽然视图不存储数据，但每次查询都能拿到最新计算值，对轻量级项目来说足够用了。
SQLite视图能否替代计算列？
直接替代说不上，但做出等效效果完全可行。SQLite不支持GENERATED ALWAYS AS计算列语法，也没有存储计算结果的能力；但视图可以封装SELECT表达式，在查询时动态计算——这恰恰是最常用、最轻量的模拟方式。换句话说，视图承担了“计算层”的角色，只不过结果不落盘。
创建视图模拟计算列的正确写法
关键不是“定义列”，而是把计算逻辑写进视图的SELECT字段里。假设有表orders，包含price和qty，想模拟一个total列，可以这样写：
CREATE VIEW orders_with_total ASSELECT *, price * qty AS totalFROM orders;
之后查询SELECT * FROM orders_with_total就能看到total字段，而且每次查询都是实时计算的。
- 必须用
SELECT *或显式列出所有原表字段，否则会丢失原始列 - 别在视图里用
ORDER BY或LIMIT——它们在视图定义中被忽略（除非加OFFSET 0强制物化，但不推荐） - 视图名建议带后缀
_view或_with_*，避免和基表混淆
WHERE条件能下推到基表吗？
能，而且这是SQLite优化器做得不错的地方。通常视图外层的WHERE条件会自动下推到基表扫描，只要表达式里不含那些不可下推的“钉子户”比如子查询、某些函数。举个例子：
SELECT * FROM orders_with_total WHERE total > 100;
SQLite实际执行的是SELECT *, price * qty AS total FROM orders WHERE price * qty > 100（或等价形式），并不会傻乎乎地把所有total算出来再过滤。
- 如果计算列依赖
CASE或COALESCE等函数，下推仍然有效；但要是用了strftime()处理非索引日期字段，索引可能就帮不上忙了 - 对性能敏感的场景，可以在基表相关字段上建索引，比如
CREATE INDEX idx_orders_price_qty ON orders(price, qty) - 别在视图里用
CAST(... AS TEXT)之类把原字段包一层——这很容易阻止索引使用
为什么不能在视图上直接INSERT/UPDATE？
因为视图本质上是只读逻辑层。SQLite默认禁止对包含表达式、*、聚合或连接的视图做DML操作。就算只是简单如price * qty AS total，也足够让视图变成non-updatable。
- 唯一可更新的视图是那种“单表+无表达式+无聚合+显式列名”的，比如
SELECT id, name FROM users - 如果业务需要写入时自动计算，得靠触发器（
CREATE TRIGGER）在INSERT/UPDATE时填充真实列，而不是依赖视图 - 试图对计算列视图执行
UPDATE ... SET total = 200会报错：attempt to assign to non-updatable column
所以结论很清楚：如果真的需要“模拟计算列”并且还要支持写入，那就得放弃视图方案，改用真实列加上触发器来维护，或者在应用层保证写入一致性——视图只负责读取侧的“实时计算”，不包写入。
