可以，但必须满足「应用层不依赖 SELECT *、不依赖 DESCRIBE、不使用 %ROWTYPE 声明记录类型」这三个硬性前提；否则会出错或漏数据。INVISIBLE列专用于在线迁移过渡期的列管理，如旧字段phone替换为phone_encrypted，通过INVISIBLE实现灰度切换，但DESCRIBE、INSERT VALUES、%ROWTYPE等操作易暴露问题，且ALTER MODIFY INVISIBLE会改变column_id和物理位置，影响ETL及优化器行为。
直接回答：可以，但必须满足「应用层不依赖 select *、不依赖 describe、不使用 %rowtype 声明记录类型」这三个硬性前提；否则会出错或漏数据。
INVISIBLE列在表升级中的真实作用场景
它不是为“无感加字段”设计的通用方案，而是专用于在线迁移（online application migration）中过渡期的列管理——比如你想把旧字段 phone 替换为新字段 phone_encrypted，又不能停机改应用代码。
- 先用
ALTER TABLE t ADD phone_encrypted VARCHAR2(100) INVISIBLE加新列，应用完全无感知 - 后台跑批把
phone值加密写入phone_encrypted - 等所有业务逻辑都切换到显式读写
phone_encrypted后，再把phone设为INVISIBLE，最后删掉 - 整个过程对老 SQL（如
SELECT * FROM t）返回结果结构完全不变
哪些地方会意外暴露或报错？
看似“隐形”，实则处处有坑。最容易翻车的是开发和运维日常操作：
-
DESCRIBE t看不到 invisible 列 → 导致开发误以为字段不存在，手动补 INSERT 语句时漏掉该列 -
INSERT INTO t VALUES (...)会报ORA-00913: too many values，因为 invisible 列仍占位置，但*不展开它 - PL/SQL 中
DECLARE r t%ROWTYPE;不包含 invisible 列 → 若后续代码用r.phone_encrypted := ...会编译失败 - 某些 ORM（如旧版 MyBatis 的自动 resultMap）可能基于
DESCRIBE生成映射，导致字段丢失
ALTER TABLE MODIFY xxx INVISIBLE 的副作用
执行后，该列在数据字典中 column_id 变为 NULL，且物理位置被移到表定义末尾 —— 这会影响依赖列序的逻辑，比如某些 ETL 工具用位置匹配字段。
- 执行
ALTER TABLE t MODIFY c1 INVISIBLE后，SELECT * FROM t返回的列顺序里c1消失，但SELECT c1, c2 FROM t仍可查 - 如果已有分区表按
c1分区，c1设为 invisible 后分区定义依然有效，但EXPLAIN PLAN显示访问路径可能变差（优化器对 invisible 列统计信息默认不收集） - 不能对系统生成的隐藏列（如
ORA_ROWSCN、虚拟列的隐式支撑列）执行MODIFY ... VISIBLE，会报ORA-30755: cannot make system generated hidden columns visible
真正要“不改代码升级表”，核心不是靠 invisible 列藏起来，而是靠应用层彻底放弃 SELECT * 和位置依赖；invisible 只是帮你多争取几周灰度时间，不是免死金牌。
