PostgreSQL执行查询时提示 relation "orders" does not exist，不一定代表表被删除。连接到了别的数据库、表在另一个schema、名字大小写不一致，都可能让当前会话找不到它。这个错误对应SQLSTATE 42P01。
先确认连接身份与对象位置，再考虑改SQL或迁移脚本。直接新建一个同名表，可能把数据写入错误位置。
先确认数据库与当前身份
SELECT current_database(), current_user, current_schema();
SHOW search_path;在报错的同一个连接里执行，比另开一个管理员会话更准确。应用的连接字符串还要核对数据库名、主机、端口与运行环境，避免把预发布库误当成生产库。不同数据库中的同名表互不可见。
查找对象真正所在的schema
SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_name = 'orders'
ORDER BY table_schema;把示例表名替换成报错对象；视图或权限不足时还应结合 pg_catalog.pg_class 与 pg_catalog.pg_namespace 查找，且需要适当权限。先确认对象确实存在、类型正确，再处理名称解析。
理解search_path的查找顺序
PostgreSQL官方文档说明，未带schema的对象名按当前 search_path 查找；不在搜索路径中的对象，可以通过 schema_name.orders 这种限定名称引用。可用 SELECT current_schemas(true); 查看当前有效路径。
生产应用优先使用明确的schema限定名，或针对连接角色审慎设置路径。把不可信用户可创建对象的schema加入搜索路径存在安全风险，不应只为消除报错而随意扩大路径。
检查带引号名称的大小写
未加双引号的SQL标识符会折叠为小写；创建表时若用了带引号的混合大小写名称，随后查询必须准确引用。例如创建 "Orders" 后，SELECT * FROM orders 寻找的是另一个名字。
不要凭应用模型类名推断数据库物理表名。查询实际目录和迁移记录，统一ORM映射、引用方式与数据库命名约定。
区分缺表与权限不足
42P01 表示未解析到目标relation；权限错误是不同的诊断路径。对象存在但当前角色没有schema USAGE或表权限时，应按具体报错核对授权，不能把所有失败都归为找不到表。
对照应用执行的完整SQL、数据库迁移状态和连接角色。生产环境不应为了试错就授予超级用户或全库权限，权限变更应按实际读写需求确定。
修正引用并在原连接中验收
核对迁移是否执行在目标数据库后，按对象真实名称修正SQL或ORM映射。用应用同一角色、同一连接参数运行只读查询，确认返回的是预期表结构和数据；写入路径应在受控窗口另行验证。
若需要重建相同数据库结构做隔离验证，可在 萤光云 或 LightNode 的测试实例上使用脱敏数据。验收标准是应用原始连接能定位正确对象，而非管理员账号查询成功。
FAQ
在数据库客户端能看到表，应用却报错？两者可能连接了不同数据库或使用不同search_path、角色和表名大小写。
把public加到search_path就能解决吗？先确认真实schema；扩大路径会改变名称解析和信任边界，限定名称往往更明确。
温馨提示
先保留原始SQL、SQLSTATE与连接环境，再改迁移或配置，防止在错误数据库中创建同名对象。
