软件定义资产是Dagster 1.3+中AssetKey与计算逻辑强绑定的一等公民，通过@asset装饰器声明，实现元数据、依赖、物化方式全代码定义，强调“定义即契约”。
什么是软件定义资产（Software-Defined Asset）
它不是新概念包装，而是 Dagster 1.3+ 中把 AssetKey 和计算逻辑真正绑定后的第一类公民。你写一个函数，加个 @asset 装饰器，Dagster 就自动把它当资产注册——元数据、依赖、物化方式全由代码定义，不靠 YAML 或外部配置。
关键在“定义即契约”：只要函数签名和装饰器参数没变，Dagster 就认为这个资产的语义没变；改了 key 或 deps，就视为新资产或依赖变更，调度图会重算。
@asset 装饰器里哪些参数不能乱动
key、deps、group_name 这三个字段一旦上线运行，修改后容易触发非预期重执行或元数据断裂。比如把 @asset(key=AssetKey(["sales", "orders"])) 改成 ["sales", "order"]，Dagster 会当成全新资产，历史物化记录丢失。
-
key建议用字符串列表，避免用动态生成值（如f"table_{env}"），否则本地开发和生产环境 key 不一致 -
deps必须显式声明上游资产，不能靠函数调用隐式推断；漏写会导致调度图断开，但不会报错，只会在 UI 里显示“no dependencies” -
compute_kind和description可随时改，不影响调度逻辑，只影响 UI 展示和日志归类
资产物化失败时，常见错误信息怎么看
最常卡在 dagster._core.errors.DagsterInvalidDefinitionError: Asset 'xxx' has no definition for asset key 'yyy'——这通常是因为你在 @asset(deps=[AssetKey(...)]) 里写的 key，在当前模块里根本没定义对应资产，或者拼写大小写/下划线不一致。
立即学习“Python免费学习笔记（深入）”；
另一个高频报错是 dagster._core.errors.DagsterInvariantViolationError: Tried to load asset 'zzz' which was not included in the provided assets，说明你用了 load_assets_from_modules 或 load_assets_from_package_module，但目标资产函数没被 import 进来，或者文件没被 Python 解释器发现（比如文件名带 _ 开头或没加 __init__.py）。
- 检查
AssetKey字符串是否和实际定义的@asset(key=...)完全一致（包括空格和层级） - 运行
dagster dev后点进 Assets 页面，看左侧树状列表有没有你的资产名；没有，大概率是 import 链断了 - 别在
@asset函数里直接调用另一个@asset函数——这不是 DAG 依赖，只是普通函数调用，Dagster 不感知
和传统 job/op 对比，资产模式下怎么调试单个函数
不能直接 python my_asset.py 运行带 @asset 的函数——它会被包装成 AssetNode，脱离上下文后连 context 都拿不到。调试必须走 Dagster 的执行路径。
- 用
dagster asset materialize -a my_asset_name在 CLI 单跑，这是最接近真实物化的方式 - 在函数开头加
print(context.asset_key.to_user_string())确认当前上下文是否正确 - 如果依赖其他资产，先确保它们已物化（
dagster asset materialize -a upstream_asset），否则会报MissingAssetExecutionError - 想跳过 IO manager 拿原始返回值？临时把函数改成普通函数，去掉
@asset，手动传 mock context——但注意这和真实执行路径已有偏差
资产不是语法糖，它是调度粒度和可观测性的锚点。一旦开始用 @asset，就等于把数据血缘、重试策略、监控指标都交给了 Dagster 的运行时；改 key、删 deps、混用 @op 和 @asset，都会让这些能力悄悄失效。
