Oracle 23c 的 JSON 表函数在 .NET 8 中不直接可用，需手写 SQL 调用 JSON_EXISTS、JSON_VALUE 或 JSON_TABLE；EF Core 仅将 JSON 列映射为 string/byte[]，无法自动翻译 JSON 查询谓词或结构化展开。
Oracle 23c 的 JSON 表函数在 .NET 8 中不直接可用
Oracle 23c 引入了 JSON_TABLE、JSON_OBJECT、JSON_ARRAY 等原生 JSON 关系映射能力，但这些是数据库端的 SQL 功能，不是 .NET 驱动层自动翻译的“特性”。.NET 8 本身不感知 Oracle 的 JSON 二元性（即同一列可同时作为 JSON 文本和关系视图访问），它只把 Oracle 当作标准关系型数据源对待。
这意味着：你不能靠 Entity Framework Core 自动把 JSON 列映射成 C# 对象树并同步支持字段级谓词下推——除非你显式写 SQL 或用 Oracle 提供的扩展。
关键限制点：
-
Oracle.ManagedDataAccess（ODP.NET Core）v23.x 虽支持 23c，但未封装JSON_TABLE为 LINQ 可用的 API - EF Core 8 不识别
JSON列类型，会将其映射为string或byte[]，无法生成带JSON_EXISTS/JSON_VALUE的 WHERE 子句 - 即使你用
FromSqlRaw手写JSON_TABLE，EF Core 也无法自动跟踪其返回结构（需手动定义匿名类型或实体）
想用 JSON_EXISTS 或 JSON_VALUE 必须手写 SQL 查询
要在 .NET 8 中真正利用 Oracle 23c 的 JSON 查询能力，得绕过 EF Core 的 LINQ 翻译，直接执行含 JSON 函数的 SQL。这是目前最可靠的方式。
例如，假设有个 products 表，其中 attributes 是 JSON 类型列，你想查 “颜色为 red 且尺寸大于 40 的商品”：
SELECT * FROM products WHERE JSON_EXISTS(attributes, '$?(@.color == "red" && @.size > 40)');
在 C# 中调用：
var results = context.Products
.FromSqlRaw("SELECT * FROM products WHERE JSON_EXISTS(attributes, '$?(@.color == \"red\" && @.size > 40)')")
.ToList();注意要点：
- 双引号必须转义（
\"），否则 C# 字符串解析失败 -
JSON_EXISTS第二个参数是字符串字面量，不能参数化（Oracle 不允许绑定变量用于路径表达式） - 若需动态路径，只能拼接字符串（务必校验输入，防注入）
-
JSON_VALUE可用于投影单个字段，但返回类型需显式转换（如JSON_VALUE(attributes, '$.price' RETURNING NUMBER)）
用 OracleCommand 执行 JSON_TABLE 获取关系化结果
当你要把 JSON 数组展开为行（比如 items 字段是个 JSON 数组，想每项变成一行），就得用 JSON_TABLE —— 它是 Oracle 23c 实现 JSON 关系二元性的核心机制。
示例：从 orders 表的 line_items JSON 字段中提取每项的 sku 和 qty：
SELECT o.id, jt.sku, jt.qty
FROM orders o,
JSON_TABLE(o.line_items, '$[*]'
COLUMNS (
sku VARCHAR2(50) PATH '$.sku',
qty NUMBER PATH '$.qty'
)
) jt;在 .NET 8 中这样调用：
using var cmd = new OracleCommand(sql, connection);
// 注意：JSON_TABLE 的 PATH 表达式不能参数化，所以这里不加参数
var reader = cmd.ExecuteReader();
while (reader.Read())
{
Console.WriteLine($"{reader["id"]}, {reader["sku"]}, {reader["qty"]}");
}重要提醒：
-
JSON_TABLE返回的是标准结果集，不是 JSON，因此能被任意 .NET 数据访问层消费 - 路径表达式中的单引号、括号、美元符容易出错，建议先在 SQL Developer 里验证好再搬进代码
- 性能上，
JSON_TABLE在 23c 中已优化为内联执行，但若 JSON 很大或嵌套深，仍可能比纯关系表慢
Entity Framework Core 中 JSON 列只能做“容器式”处理
如果你坚持用 EF Core 的实体映射，JSON 列只能当作黑盒字符串存取。你可以用 System.Text.Json 手动序列化/反序列化，但所有 JSON 内容的查询逻辑必须退回到应用层（即先取整条 JSON 字符串，再用 C# 解析过滤）。
例如：
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public string Attributes { get; set; } // 映射为 string，不是 JsonDocument
}然后手动解析：
var products = context.Products.ToList();
var redLarge = products
.Where(p => JsonDocument.Parse(p.Attributes)
.RootElement.TryGetProperty("color", out var color) &&
color.GetString() == "red" &&
JsonDocument.Parse(p.Attributes)
.RootElement.TryGetProperty("size", out var size) &&
size.GetInt32() > 40);这种做法的问题很实在：
- 无法下推谓词，全量拉取再内存过滤，数据一多就卡
- 重复解析同一字段多次，CPU 开销明显
- 丢失 Oracle 对 JSON 的索引支持（比如对
$.color建函数索引）
真正要用好 JSON 关系二元性，就得接受一个事实：SQL 层才是主战场，C# 层只是消费方。别指望 ORM 自动帮你桥接 JSON 和关系语义——Oracle 23c 没提供这个桥，ODP.NET 也没造这个轮子。
