1 基本概念
1.1 定义
只读标识符是指在对象、记录或资源创建后保持不变的标识字段。它的主要作用不是描述内容，而是为系统提供一个稳定的“身份坐标”，便于在不同模块、不同时间点准确定位同一实体。与普通可编辑字段相比，它更强调持久性和一致性。
在信息系统中，这类字段常出现在数据库记录、接口返回结果、文档条目和配置项中。即使对象的名称、状态、备注等内容发生变化，只读标识符通常仍保持原样，从而避免引用失效或关联混乱。
1.2 核心特征
只读标识符通常具有三个共同特征：唯一性、不可变性和可引用性。它们共同构成了此类字段的基础价值，使其能够承担“身份识别”职责。
1.2.1 唯一性
唯一性指同一作用范围内不会出现两个完全相同的标识符。系统依赖这种特性来区分不同对象，避免记录混淆。若标识符不能唯一指向某一实体，后续的数据关联、检索和同步都容易产生歧义。
1.2.2 不可变性
不可变性是只读标识符最重要的特征之一。该字段一旦生成，通常不允许被直接修改。这样做的目的在于维持历史记录、外部引用和内部关联的连续性，减少因标识变化而带来的连锁影响。
1.2.3 可引用性
可引用性是指标识符能够被其他数据结构、接口或文档稳定调用。它不仅是一个识别值，也常被用作关联键、查询条件或日志中的追踪线索。由于其长期稳定，系统可以围绕它建立可靠的数据链路。
1.3 与其他字段的区别
只读标识符常与名称、状态等字段并列出现，但它们承担的职责并不相同。前者偏向“识别”，后者偏向“描述”或“表达当前情况”。
1.3.1 与名称字段的区别
名称字段通常用于人类阅读和理解，允许根据业务需要修改，例如商品名、文件名或项目标题。而只读标识符更像系统内部的身份凭证，即使名称变化，也不应随之改变。两者常常同时存在，以兼顾可读性和稳定性。
1.3.2 与状态字段的区别
状态字段用于表示对象当前所处阶段，如启用、停用、草稿、已完成等，具有明显的动态属性。只读标识符则不随状态变化而变化，其职责是确保无论对象处于何种状态，都能被持续、准确地识别。
2 技术实现
2.1 数据库中的实现
在数据库层面，只读标识符通常通过主键、唯一键或专门的只读列来实现。其设计目标是让标识字段在存储层面受到约束，避免被随意改动。
2.1.1 主键与只读列
主键是最常见的实现方式之一，数据库会自动保证其唯一性，并限制重复。某些场景下，主键之外还会设置业务只读列，例如外部编号、档案号或编码字段。前者用于内部关联，后者则更便于业务系统展示和检索。
2.1.2 自增标识与UUID
自增标识符常见于关系型数据库，生成简单、存储紧凑，适合内部系统使用。UUID则更适用于分布式环境，能够在多节点、离线生成等条件下保持较低的冲突概率。二者都可作为只读标识符，但在可读性、排序性和长度上各有特点。
2.2 软件界面中的实现
在界面层，开发者通常会将只读标识符设置为不可编辑控件，或仅以展示形式呈现。这样既能让用户看到必要的身份信息，也能减少误操作。
2.2.1 表单只读控件
表单中的只读控件会显示标识值，但禁止直接输入或改写。常见形式包括灰显输入框、文本标签或复制按钮配合展示。此类设计既能保留查阅功能，也能在交互上明确提示“此项不可修改”。
2.2.2 详情页展示逻辑
在详情页中，只读标识符通常被放置在信息区的显著位置，例如记录编号、资源ID或订单号。它往往与创建时间、所属分类等辅助信息并列展示，帮助用户快速确认当前对象的身份，并在沟通、报障或检索时提供依据。
2.3 接口层中的实现
在接口设计中，只读标识符通常作为返回值中的固定字段出现，同时在请求参数中受到保护，防止被客户端随意篡改。
2.3.1 API返回值中的标识符
API返回的数据一般会包含对象ID、记录编号或资源路径等字段，用于后续查询、更新和关联。只读标识符在返回结果中通常保持统一命名和格式，以便不同服务之间稳定对接。
2.3.2 请求参数中的保护机制
对于更新、删除或引用类请求，接口通常只允许客户端提交目标标识符，而不允许改写该字段本身。常见做法包括校验参数来源、忽略非法提交、在服务端二次确认身份等。这样可以减少前端误传、恶意伪造或同步冲突带来的风险。
3 应用场景
3.1 用户账户系统
在用户账户系统中，只读标识符常用于区分不同账号实体，例如用户ID、工号或会员编号。即便用户名、昵称、头像等信息发生变化，系统仍能依靠固定标识追踪同一账户，确保登录、权限、消息和记录保持连贯。
3.2 商品与订单管理
商品、订单和发票等对象通常都需要稳定编号。商品名称可能会调整，订单内容也可能涉及备注修正，但订单号、商品编码等只读标识符不会随之更改。它们在库存、支付、售后和对账环节中起到关键作用。
3.3 文件与资源管理
文件管理系统往往会为资源分配唯一ID，用于定位上传后的文件、图片、视频或附件。文件名可能被重命名，存储路径也可能迁移，但只要标识符保持不变，系统就能继续正确访问该资源，避免链接断裂。
3.4 日志与审计系统
日志和审计系统强调可追踪性，因此常为事件、会话、操作记录设置不可变标识。通过这些标识符，系统可以将多个片段串联起来，形成完整的操作链路，便于回溯、排查和统计分析。
4 设计原则
4.1 稳定性优先
设计只读标识符时，通常应把稳定性放在首位。只要标识符被广泛引用，就应尽量避免后续重构或替换，以免影响依赖它的接口、报表和历史数据。
4.2 避免业务语义绑定
过度依赖业务语义来生成标识符，容易在规则变化后造成问题。例如当编码包含地区、年份或类别信息时，一旦业务调整，原有标识便可能显得不再适用。因此，较理想的做法是让标识符尽量保持“无语义”或“弱语义”。
4.3 防止人工误改
只读标识符一旦被误改，可能引发关联断裂、重复记录或同步异常。为此，系统常采用权限限制、界面锁定、数据库约束和审计记录等方式，降低人为操作风险。对于关键标识，还会增加校验与回滚手段。
4.4 支持长期追踪
长期追踪要求标识符在较长时间跨度内仍能指向同一对象。无论对象经历名称变更、状态转换、归档迁移还是跨系统同步，只读标识符都应尽量维持一致，以便保留历史链路和上下文信息。
5 常见问题
5.1 标识符是否可以重新生成
通常不建议随意重新生成。若确有特殊需要，例如系统迁移、历史数据修复或冲突消解，应在充分评估影响后进行，并同步更新所有关联引用。否则，重新生成很容易导致旧链接失效或记录对不上。
5.2 只读标识符是否一定对用户隐藏
不一定。是否展示取决于业务场景。对普通用户而言，标识符可能只作为辅助信息出现；对管理员、客服或开发人员来说，则常需要直接查看甚至复制使用。只读并不等于隐藏，而是强调不可编辑。
5.3 如何处理迁移与同步
在迁移与同步过程中，通常需要保留原有标识的映射关系。若目标系统无法直接沿用旧ID，可建立中间映射表或外部编号对照表，确保历史数据、外部链接和同步任务仍可正确对应到目标对象。
5.4 与权限控制的关系
只读标识符与权限控制是两个不同层面的概念。前者关注字段是否允许修改，后者关注谁可以查看、操作或访问对象。一个字段即使被设计为只读，也仍可能因权限不足而不可见；反过来，具备查看权限也不代表拥有修改权。
6 扩展概念
6.1 半只读标识符
半只读标识符指在多数情况下保持不变，但在特定条件下允许调整的标识形式。例如系统早期采用的编号规则，在后续统一规范时可能会被替换。这类设计兼顾历史兼容与业务演进，但管理成本也更高。
6.2 派生标识符
派生标识符通常由其他字段计算或组合而成，例如日期加序号、分类码加流水号等。它的可读性往往较强，但稳定性取决于组成规则是否长期有效。一旦上游字段变化，派生结果也可能需要重算。
6.3 外部系统标识符
外部系统标识符是用于跨平台对接的编号，常见于数据交换、第三方服务或联合管理场景。它未必是本地数据库主键，但对外部系统来说却承担着唯一定位作用，因此也经常被设为只读。
6.4 复合标识符
复合标识符由多个字段共同构成，用于共同确定对象身份，例如“地区+年份+序号”或“项目+版本+分支”。这种方式能够增强区分度，但在修改任一组成部分时都可能影响整体标识，因此通常需要更谨慎的设计。