FeatureColumn本质是声明式特征配置协议，不自动做清洗缩放编码，要求输入为键匹配的字典张量；需用tf.data+map预处理原始数据，集成Keras时用DenseFeatures层但注意签名一致性和哈希桶风险。
FeatureColumn 本质是“配置描述”，不是自动特征工程工具
TensorFlow 的 tf.feature_column 不会自动清洗、缩放或编码原始数据，它只是为 Estimator 或 Keras 模型（配合 tf.keras.layers.DenseFeatures）提供一种**声明式定义特征如何被解析和转换的协议**。你传给它的输入必须已经是结构化张量（如 tf.Tensor 或 tf.SparseTensor），或者来自 tf.data.Dataset 的字典格式样本。
常见错误现象：ValueError: Feature .* is not in features dictionary 或 TypeError: Expected string, got int —— 这往往是因为原始 CSV/NumPy 数据没按列名组织成 dict，或字符串/数值类型没对齐。
- 输入数据必须是字典：键为列名（需与
feature_column中指定的key完全一致），值为tf.Tensor（dense）或tf.SparseTensor（categorical） -
tf.feature_column.categorical_column_with_vocabulary_list要求输入是字符串张量；若原始字段是整数 ID，得先用tf.as_string或预处理转成字符串 - 数值列（
numeric_column）默认不归一化，要标准化得自己加tf.keras.layers.Normalization层，或在tf.data流水线中用map预处理
用 tf.data + map 构建可复用的预处理流水线
把原始 CSV/Parquet 数据转成符合 FeatureColumn 要求的字典格式，最可控的方式是写一个纯 Python 函数 + tf.py_function，再封装进 tf.data.Dataset.map。这样训练/推理时能复用同一套逻辑。
使用场景：读取 CSV 文件后，需做缺失值填充、字符串转小写、类别字段截断长尾、数值字段 clip 等——这些都不能靠 feature_column 完成。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 示例关键步骤：
def parse_csv_row(line): fields = tf.io.decode_csv(line, record_defaults=DEFAULTS) features = dict(zip(COLUMN_NAMES, fields)) # 手动处理：填充空字符串、转小写、clip 数值 features["city"] = tf.where(tf.equal(features["city"], ""), "unknown", features["city"]) features["price"] = tf.clip_by_value(features["price"], 0.0, 1e6) return features - 之后用
dataset.map(parse_csv_row)得到标准字典格式，直接喂给DenseFeatures层 - 注意：所有
tf.py_function内部操作必须用 TensorFlow 原生 op（不能用 pandas/numpy），否则无法图模式导出
FeatureColumn 和 Keras 模型集成的两种方式
Estimator API 已趋于维护模式，现在主流是用 tf.keras.layers.DenseFeatures 把 feature_column 接入 Keras 模型。但要注意它只接受 dict 输入，且输出是拼接后的 dense 张量，没有保留原始字段语义。
性能影响：DenseFeatures 层会在图构建期展开所有列逻辑（比如 embedding lookup、bucketing），模型保存后体积可能显著增大，尤其当 vocabulary 很大时。
- 推荐写法：
feature_layer = tf.keras.layers.DenseFeatures(feature_columns) model = tf.keras.Sequential([ feature_layer, # 输入必须是 dict，输出是 (batch, total_feature_dim) tf.keras.layers.Dense(64, activation='relu'), tf.keras.layers.Dense(1, activation='sigmoid') ]) - 如果要用函数式 API 并保留字段粒度（例如不同字段走不同子网络），就得绕过
DenseFeatures，改用每个feature_column单独调用tf.keras.layers.Input+ 对应转换层（如tf.keras.layers.StringLookup），但这已脱离传统feature_column范式 - 导出 SavedModel 后，签名函数的输入 signature 是 dict，字段名必须与
feature_column的key严格一致，否则线上推理报KeyError
为什么 categorical_column_with_hash_bucket 容易踩坑
这个列类型看似“免维护”（不用提前知道全部类别），实际在生产中极易导致训练/推理不一致，因为哈希桶分配依赖输入字符串的字节表示和哈希种子，而 TF 默认种子不可控。
错误现象：同样一条样本，在训练时分到 bucket 5，在 serving 时分到 bucket 12，embedding 查表错位，模型效果归零。
- 必须显式设置
hash_bucket_size和dtype=tf.string，并确保输入确实是字符串（不是 int 编码后误当字符串） - 更稳妥的做法是弃用 hash bucket，改用
categorical_column_with_vocabulary_file或categorical_column_with_vocabulary_list，把 vocab 固化进模型包 - 如果真要用 hash，务必在训练和导出时固定
tf.random.set_seed，且确认 TF 版本在训练和服务端完全一致（不同版本哈希算法可能微调）
训练数据预处理逻辑和 serving 时的输入解析逻辑必须完全同步，哪怕一行 strip() 的有无，都可能导致 feature_column 解析失败或语义偏移。
