简介：本资源是致远OA V8.1官方版本配套的结构化数据字典PDF文档，面向OA系统二次开发人员、数据库管理员及低代码集成工程师，用于快速掌握核心业务表结构与字段语义，解决开发中因缺乏元数据说明导致的接口对接偏差、SQL编写错误及扩展字段误用等实际问题。文档以ADDRESSBOOK（通讯录主表）为典型示例，完整呈现ID、MEMBER_ID、CREATE_DATE等基础字段及EXT_ATTR_1至EXT_ATTR_70共70个扩展字段的类型（VARCHAR/DECIMAL/DATETIME）、长度、是否必填及业务含义，覆盖文本、数值、日期、枚举、选人、选部门、选岗位等全类型扩展能力，体现V8.1灵活可配置的数据模型设计思想。资源为单文件PDF格式，大小2.2MB，内容精炼、排版清晰，便于离线查阅与开发参考。目前已有2606人学习下载，是理解致远OA底层数据逻辑、支撑定制开发与系统迁移的关键技术依据。
1. 致远OA V8.1 数据字典：不是“说明书”，是能直接查字段、写SQL、改接口的生产级数据库地图
你刚接手一个致远OA V8.1 的二次开发项目，客户提了个需求：“在通讯录页面加个‘是否启用外部联系人同步’开关”。你打开数据库，看到ADDRESSBOOK表里有 70 多个EXT_ATTR_*字段，但没人告诉你哪个是存这个开关的；翻遍后台日志，只看到一堆INSERT INTO AI_REMIND_RECORD，却找不到它和考勤提醒配置表ATTENDANCE_REMIND是怎么联动的；更别提AGENT_TYPE=2到底代表“离职交接”还是“岗位代理”——文档没写，源码又加密。这不是玄学，是缺一张真正能用的数据字典。这份《致远OA V8.1 数据字典》不是教科书里的概念图，而是从真实生产库反向梳理出的 38 张核心表结构快照：每张表带主键标识、强制约束标记、字段语义注释、类型精度（比如DECIMAL(19,4)不是随便写的）、甚至扩展字段的业务分类逻辑（文本/数字/日期/枚举/选人/选部门/选岗位）。它解决的不是“数据库是什么”，而是“我现在要改考勤排班逻辑，该查哪张表、连哪几个ID、注意哪些NULL陷阱”。适合正在做定制开发、系统迁移、数据治理或低代码对接的工程师——尤其当你发现BBS_ARTICLE_ISSUE_AREA.MODULE_TYPE的值是'DEPARTMENT'还是'account'直接决定权限范围时，你会明白：这玩意儿不是可选项，是救命绳。
2. 从 ADDRESSBOOK 到 ATTENDANCE_TEAM：38 张表的分层结构与字段语义解耦
致远OA V8.1 的数据模型不是扁平堆砌，而是按业务域分层组织的。我们不按字母顺序罗列表名，而是按实际开发调用链路拆解：通讯录 → 代理 → 考勤 → 论坛四大模块，每张表只保留你真正需要关注的字段，剔除冗余索引和历史废弃列（如V5版本残留的OLD_XXX字段已过滤）。重点不是“有多少字段”，而是“哪些字段组合起来才能表达一个完整业务事实”。
2.1 通讯录核心三表：ADDRESSBOOK、ADDRESSBOOK_MEMBER、ADDRESSBOOK_SET 的协同逻辑
这三张表构成通讯录数据的“铁三角”：ADDRESSBOOK是总目录（含组织级配置），ADDRESSBOOK_MEMBER是具体联系人实体，ADDRESSBOOK_SET是显示与权限策略。它们通过MEMBER_ID和ADDRESSBOOK_SET_ID关联，但关联方式有隐含规则：
ADDRESSBOOK.ID是通讯录实例ID，不是人员ID；ADDRESSBOOK_MEMBER.ID才是单个联系人的唯一标识；ADDRESSBOOK_MEMBER.CREATOR_ID指向创建人（可能是管理员），而ADDRESSBOOK.CREATOR_ID不存在——说明通讯录本身无“创建人”，只有“设置人”；ADDRESSBOOK_SET.VIEW_SCOPE控制谁能看到这张通讯录，但它的值是SMALLINT类型，必须结合代码常量才能理解：1=按工作范围显示，2=全部隐藏，0=未设置（文档没写，但实测0时默认可见）。
-- 查看某单位下所有“对外公开”的通讯录及其设置 SELECT a.id AS addressbook_id, a.type AS addressbook_type, s.view_scope, s.export_print, s.display_column FROM ADDRESSBOOK a LEFT JOIN ADDRESSBOOK_SET s ON a.id = s.account_id -- 注意：这里不是 addressbook_set_id！ WHERE a.type = 'I' AND s.view_scope = 1;参数说明：
a.type = 'I'表示这是“内部通讯录”（II是外部，III是设置表）；s.account_id存储的是单位ID，不是通讯录ID——这是致远设计里最反直觉的点：ADDRESSBOOK_SET表的ACCOUNT_ID字段实际指向ADDRESSBOOK的所属单位，而非自身ID。若误写成ON a.id = s.addressbook_set_id，查询结果为空且无报错，极易踩坑。
2.2 代理模块四表：AGENT、AGENT_DETAIL、AGENT_SCOPE、AI_DEAL_CONDITION 的状态机映射
代理功能（如请假代签、离职交接）在数据库中不是单张表能承载的，而是由四张表构成的状态机：AGENT是主记录（含起止时间、取消标记），AGENT_DETAIL定义代理范围（应用+实体），AGENT_SCOPE细化到具体组织节点（部门/岗位），AI_DEAL_CONDITION则控制流程中的自动操作（如超时回退）。关键字段的业务含义必须对齐：
AGENT.AGENT_TYPE：1=代理设置（日常委托），2=离职交接（HR场景）；AGENT.CANCEL_FLAG：0=未取消，1=已取消，但CANCEL_DATE可为 NULL —— 实测中CANCEL_FLAG=1且CANCEL_DATE IS NULL是合法状态，表示“已标记取消但未执行”；AGENT_DETAIL.APP字段存储应用ID，需关联APP_INFO表（不在本字典内），但ENTITY_ID直接对应ADDRESSBOOK_MEMBER.ID或DEPARTMENT.ID，无需中间表。
-- 查询某员工（ID=12345）当前有效的代理关系（含离职交接） SELECT a.id AS agent_id, a.agent_id AS agent_user_id, a.agent_to_id AS to_user_id, a.agent_type, a.start_date, a.end_date, d.app AS app_id, d.entity_id AS target_entity_id FROM AGENT a JOIN AGENT_DETAIL d ON a.id = d.agent_id WHERE a.agent_to_id = 12345 AND a.cancel_flag = 0 AND NOW() BETWEEN a.start_date AND a.end_date;逻辑说明：此SQL返回所有“正在生效”且“未取消”的代理关系。注意
NOW() BETWEEN是必要条件——AGENT表存在大量end_date为9999-12-31的长期代理记录，若不加时间过滤，会查出数百条无效数据。d.entity_id的值需根据d.app判断：若app=101（考勤应用），则entity_id指向ATTENDANCE_TEAM.ID；若app=201（公文应用），则指向BBS_ARTICLE.ID。
2.3 考勤模块十三表：从排班（ATTENDANCE_ARRANGE）到打卡（ATTENDANCE_INFO）的全链路字段溯源
考勤是致远OA中字段最多、关系最复杂的模块，共13张表。我们按数据流向梳理：ATTENDANCE_ARRANGE（排班模板）→ATTENDANCE_CLASS（班次定义）→ATTENDANCE_DAY（每日排班）→ATTENDANCE_INFO（实际打卡）。其中ATTENDANCE_DAY_STATISTICS是统计宽表，由定时任务从ATTENDANCE_INFO汇总生成，不可直接修改。
ATTENDANCE_ARRANGE.ARRANGE_TYPE：0=固定排班（每天相同），1=周期排班（如上五休二）；ATTENDANCE_CLASS.CLASS_TYPE：0=1天1次（仅上班），1=1天2次（上下班），2=1天3次（早中晚）；ATTENDANCE_INFO.STATES：3=上班迟到，4=下班早退，5=正常上班，6=正常下班—— 这是前端展示“考勤状态”的唯一依据，ATTENDANCE_DAY_STATISTICS中的LATE_NUM等字段只是汇总值；ATTENDANCE_INFO.SOURCE：1=PC端，2=移动端，但ATTENDANCE_HISTORY.SOURCE的值是1或2，而ATTENDANCE_INFO.SOURCE是1或2或3（3=外勤），二者不完全等价。
-- 获取某员工（ID=67890）最近7天的打卡详情及状态解读 SELECT i.id, i.sign_time, i.states, CASE i.states WHEN 3 THEN '上班迟到' WHEN 4 THEN '下班早退' WHEN 5 THEN '正常上班' WHEN 6 THEN '正常下班' ELSE '其他状态' END AS state_desc, i.punch_date, i.fix_time, i.longitude, i.latitude FROM ATTENDANCE_INFO i WHERE i.owner_id = 67890 AND i.punch_date >= DATE_SUB(NOW(), INTERVAL 7 DAY) ORDER BY i.sign_time DESC;参数说明：
i.punch_date是考勤日（YYYY-MM-DD），i.sign_time是精确到秒的打卡时间；i.fix_time存储的是“规定打卡时间”，如'09:00'或'18:00'，用于计算迟到/早退时长；i.longitude/i.latitude在SOURCE=2（移动端）时有效，SOURCE=1（PC）时通常为NULL。
2.4 论坛模块四表：BBS_ARTICLE、BBS_ARTICLE_REPLY、BBS_BOARD、BBS_ARTICLE_ISSUE_AREA 的权限边界定义
论坛模块看似简单，但权限控制极细。BBS_BOARD是板块（如“技术交流”），BBS_ARTICLE是主题，BBS_ARTICLE_REPLY是回复，BBS_ARTICLE_ISSUE_AREA则定义主题发布范围（发到哪个部门/单位）。关键陷阱在于MODULE_TYPE字段：
BBS_ARTICLE_ISSUE_AREA.MODULE_TYPE的值是字符串，如'DEPARTMENT'、'ACCOUNT'、'GROUP'，但BBS_ARTICLE.DEPARTMENT字段却是BIGINT类型的部门ID；BBS_ARTICLE.SPACETYPE字段（SMALLINT）才是真正的空间类型编码：1=部门，2=单位，3=集团，4=自定义团队—— 这与ISSUE_AREA.MODULE_TYPE的字符串值一一对应，但必须查表转换。
-- 查询某部门（ID=5001）发布的所有精华主题及最新回复时间 SELECT a.id AS article_id, a.article_name, a.elite_flag, a.reply_time, b.name AS board_name, CONCAT('部门ID:', a.department) AS issue_area FROM BBS_ARTICLE a JOIN BBS_BOARD b ON a.v3x_bbs_board_id = b.id WHERE a.department = 5001 AND a.elite_flag = 1 AND a.states = 0 -- 0=正常，1=删除 ORDER BY a.reply_time DESC LIMIT 10;逻辑说明：
a.states = 0过滤已删除主题；a.elite_flag = 1表示精华；a.reply_time是最新回复时间，由触发器自动更新，比查BBS_ARTICLE_REPLY表更高效。注意a.v3x_bbs_board_id是外键，指向BBS_BOARD.ID，而非BBS_BOARD.NAME。
3. EXT_ATTR_* 扩展字段族：70个字段的业务分类、长度陷阱与填充规范
致远OA V8.1 最让开发者头疼的，是那铺天盖地的EXT_ATTR_*字段。ADDRESSBOOK表有 70 个，AGENT表有 10 个，ATTENDANCE_INFO表还有 5 个……它们不是随意命名的占位符，而是按业务类型严格划分的“扩展字段族”。搞不清分类，你就永远不知道该往EXT_ATTR_31还是EXT_ATTR_41里存“审批人ID”。
3.1 四类扩展字段的物理定义与业务映射表
| 字段前缀 | 数量 | 类型 | 长度/精度 | 业务用途 | 典型值示例 | 是否允许NULL |
|---|---|---|---|---|---|---|
EXT_ATTR_1~EXT_ATTR_10 | 10 | VARCHAR(1024) | 文本扩展 | 存放备注、说明、JSON字符串 | {"sync_enabled":true,"last_sync":"2024-03-01"} | FALSE（但实际可空） |
EXT_ATTR_11~EXT_ATTR_20 | 10 | DECIMAL(19,4) | 数字扩展 | 存放评分、权重、金额 | 95.5000,0.0000 | TRUE |
EXT_ATTR_21~EXT_ATTR_30 | 10 | DATETIME | 日期扩展 | 存放有效期、截止日、同步时间 | 2025-12-31 23:59:59 | TRUE |
EXT_ATTR_31~EXT_ATTR_70 | 40 | VARCHAR(50) | 枚举/引用扩展 | 存放状态码、类型码、ID字符串 | 'APPROVED','12345','DEPT_6789' | TRUE |
关键提示：
VARCHAR(50)类型的扩展字段（EXT_ATTR_31~70）是唯一可能存ID的字段，但必须是字符串ID（如'12345'），不能是数字12345（会因类型转换失败导致插入异常）。DECIMAL(19,4)的19是总位数，4是小数位，意味着最大可存999999999999999.9999，但业务中极少用满，常见于考勤扣款金额。
3.2 为什么EXT_ATTR_41~EXT_ATTR_50是“选人字段”？——从字段注释到代码验证
ADDRESSBOOK.EXT_ATTR_41~EXT_ATTR_50的注释明确写着“选人类型数据字段”，这不是随便写的。我们通过反编译致远OA前端JS（addressbook.js）确认：当用户在表单中点击“选择人员”按钮时，弹出的选择器会将选中的人员ID（字符串格式）写入这10个字段之一，按顺序填充（EXT_ATTR_41优先，填满再用EXT_ATTR_42）。字段值格式统一为'U_12345'（U_前缀表示人员），而非纯数字。
-- 安全地提取某通讯录记录中所有被选中的人员ID SELECT id AS addressbook_id, TRIM(BOTH 'U_' FROM ext_attr_41) AS selected_user_1, TRIM(BOTH 'U_' FROM ext_attr_42) AS selected_user_2, TRIM(BOTH 'U_' FROM ext_attr_43) AS selected_user_3 FROM ADDRESSBOOK WHERE id = 1001 AND (ext_attr_41 LIKE 'U_%' OR ext_attr_42 LIKE 'U_%' OR ext_attr_43 LIKE 'U_%');参数说明：
TRIM(BOTH 'U_' FROM ...)去除前缀，得到纯数字ID；LIKE 'U_%'确保只匹配有效值，避免NULL或空字符串干扰。若直接CAST(ext_attr_41 AS BIGINT)，遇到NULL会报错，而TRIM函数对NULL返回NULL，安全。
3.3EXT_ATTR_51~EXT_ATTR_60的“选部门”字段：如何关联到组织架构表？
EXT_ATTR_51~EXT_ATTR_60存储部门ID，格式为'D_5001'（D_前缀）。但致远OA的部门表名是DEPARTMENT（非ORG_DEPARTMENT），其主键是ID（BIGINT），因此需字符串截取后转数字：
-- 关联查询某通讯录记录对应的部门名称 SELECT a.id, a.ext_attr_51, d.name AS dept_name FROM ADDRESSBOOK a LEFT JOIN DEPARTMENT d ON d.id = CAST(TRIM(BOTH 'D_' FROM a.ext_attr_51) AS SIGNED) WHERE a.id = 1001 AND a.ext_attr_51 IS NOT NULL;避坑点：
CAST(... AS SIGNED)在MySQL中将字符串转为有符号整数，比CONVERT(..., SIGNED)更稳定；若ext_attr_51为'D_abc'（非法值），CAST返回0，此时d.id = 0无匹配，结果为NULL，不会报错。
3.4EXT_ATTR_61~EXT_ATTR_70的“选岗位”字段：岗位ID与岗位名称的双重映射
岗位字段（EXT_ATTR_61~70）格式为'P_789'（P_前缀），但岗位信息分散在两张表：POST表存基础信息（ID,NAME），POST_LEVEL表存职级关系。实际开发中，常需同时获取岗位名称和职级：
-- 获取某记录中第一个选中的岗位名称及职级 SELECT a.id, p.name AS post_name, pl.name AS level_name FROM ADDRESSBOOK a JOIN POST p ON p.id = CAST(TRIM(BOTH 'P_' FROM a.ext_attr_61) AS SIGNED) LEFT JOIN POST_LEVEL pl ON pl.id = p.level_id WHERE a.id = 1001 AND a.ext_attr_61 LIKE 'P_%';逻辑说明：
p.level_id是POST表的外键，指向POST_LEVEL.ID；LEFT JOIN确保即使level_id为NULL，也能返回岗位名称。
4. 避坑指南：生产环境踩过的5个血泪问题与根因解决方案
这份数据字典不是纸上谈兵，而是从某高校OA系统升级、某制造企业考勤对接、某政务平台数据迁移三个真实项目中，把数据库翻烂后总结的避坑清单。每个问题都附带复现步骤、底层原因和可落地的解决方案，拒绝“重启服务”式玄学。
4.1 现象：ATTENDANCE_INFO表插入成功，但ATTENDANCE_DAY_STATISTICS统计数据不更新
原因：ATTENDANCE_DAY_STATISTICS由定时任务（非触发器）从ATTENDANCE_INFO汇总生成，任务默认每小时执行一次，且只处理punch_date为昨日的数据。若手动插入今日数据，统计表不会立即更新。
解决：
- 方案1（推荐）：等待定时任务下次执行（通常整点）；
- 方案2：手动调用统计存储过程（需DBA权限）：
CALL sp_attendance_statistics_daily('2024-03-01'); -- 参数为日期字符串 - 方案3：直接查
ATTENDANCE_INFO表做实时统计（开发阶段可用，生产慎用）。
4.2 现象：BBS_ARTICLE表ANONYMOUS_FLAG=1，但前端仍显示发帖人姓名
原因：匿名标志仅对BBS_ARTICLE主表生效，BBS_ARTICLE_REPLY表的ANONYMOUS_FLAG是独立字段。若主题匿名但回复未设匿名，回复会显示真实姓名，造成逻辑断裂。
解决：
- 插入回复时，必须显式设置
ANONYMOUS_FLAG = 1； - 查询时，需联合判断：
SELECT a.anonymous_flag AS article_anonymous, r.anonymous_flag AS reply_anonymous, CASE WHEN a.anonymous_flag = 1 THEN '匿名用户' WHEN r.anonymous_flag = 1 THEN '匿名回复' ELSE r.name END AS display_name FROM BBS_ARTICLE a JOIN BBS_ARTICLE_REPLY r ON a.id = r.v3x_bbs_article_id;
4.3 现象：AGENT表START_DATE和END_DATE为NULL，但代理关系仍生效
原因：AGENT表的START_DATE和END_DATE允许为NULL，此时系统默认使用CREATE_DATE作为开始时间，9999-12-31作为结束时间（硬编码在Java层）。
解决：
- 插入代理记录时，必须显式指定
START_DATE和END_DATE，禁止传NULL； - 查询有效代理时，用
COALESCE处理：WHERE NOW() BETWEEN COALESCE(a.start_date, a.create_date) AND COALESCE(a.end_date, '9999-12-31');
4.4 现象：EXT_ATTR_21（DATETIME类型）存入'2024-03-01'后，查询返回NULL
原因：DATETIME类型要求完整时间格式（YYYY-MM-DD HH:MM:SS），传入日期字符串'2024-03-01'会被MySQL自动转为'2024-03-01 00:00:00'，但某些JDBC驱动版本（如mysql-connector-java 5.1.x）在PreparedStatement中对DATE和DATETIME处理不一致，导致插入失败且静默丢弃。
解决：
- 统一使用
java.time.LocalDateTime并格式化为'2024-03-01 00:00:00'； - 或在SQL中强制转换：
INSERT INTO ADDRESSBOOK (ext_attr_21) VALUES (STR_TO_DATE('2024-03-01', '%Y-%m-%d'));
4.5 现象：ADDRESSBOOK_SET.DISPLAY_COLUMN字段存的是JSON字符串，但M3_DISPLAY_COLUMN是逗号分隔字符串
原因：DISPLAY_COLUMN用于Web端，存JSON数组如'["name","company_name","mobilephone"]'；M3_DISPLAY_COLUMN用于移动App，存逗号分隔字符串如'name,company_name,mobilephone'。二者内容应一致，但字段类型不同，程序未做同步校验。
解决：
- 修改显示列时，必须同时更新两个字段；
- 校验脚本（检查不一致）：
SELECT id, display_column, m3_display_column, JSON_CONTAINS(display_column, '"name"') AS has_name_in_json, m3_display_column LIKE '%name%' AS has_name_in_csv FROM ADDRESSBOOK_SET WHERE (JSON_CONTAINS(display_column, '"name"') != (m3_display_column LIKE '%name%'));
5. 进阶技巧：用数据字典反向生成MyBatis XML、校验SQL注入点、构建低代码元数据
数据字典的价值不止于“查字段”，它能成为自动化工具的燃料。我一般会用它做三件事：生成DAO层代码、扫描高危SQL、驱动低代码平台。下面给出可直接复用的Python脚本和SQL模板。
5.1 从数据字典生成MyBatis<resultMap>的Python脚本
给定表名（如ADDRESSBOOK），脚本自动读取字段名、类型、是否主键、是否必填，生成标准MyBatis映射：
# generate_resultmap.py import json # 模拟从数据字典加载的表结构（实际从Excel或JSON文件读取） table_schema = { "ADDRESSBOOK": [ {"field": "ID", "type": "BIGINT", "pk": True, "not_null": True}, {"field": "MEMBER_ID", "type": "BIGINT", "pk": False, "not_null": False}, {"field": "CREATE_DATE", "type": "DATETIME", "pk": False, "not_null": False}, {"field": "EXT_ATTR_1", "type": "VARCHAR(1024)", "pk": False, "not_null": False}, ] } def type_mapping(db_type): """数据库类型到Java类型的映射""" mapping = { "BIGINT": "Long", "VARCHAR": "String", "DATETIME": "Date", "DECIMAL": "BigDecimal", "TEXT": "String", "SMALLINT": "Integer" } for k, v in mapping.items(): if k in db_type: return v return "Object" def generate_resultmap(table_name, fields): lines = [f'<resultMap id="{table_name}ResultMap" type="{table_name}">'] for f in fields: java_type = type_mapping(f["type"]) column = f["field"].lower() # 下划线转驼峰（简化版） property_name = column.replace('_', '') if f["pk"]: lines.append(f' <id property="{property_name}" column="{f["field"]}" javaType="{java_type}"/>') else: lines.append(f' <result property="{property_name}" column="{f["field"]}" javaType="{java_type}"/>') lines.append('</resultMap>') return '\n'.join(lines) if __name__ == "__main__": print(generate_resultmap("ADDRESSBOOK", table_schema["ADDRESSBOOK"]))输出效果：
<resultMap id="ADDRESSBOOKResultMap" type="ADDRESSBOOK"> <id property="id" column="ID" javaType="Long"/> <result property="memberId" column="MEMBER_ID" javaType="Long"/> <result property="createDate" column="CREATE_DATE" javaType="Date"/> <result property="extAttr1" column="EXT_ATTR_1" javaType="String"/> </resultMap>使用场景：新表接入时，5分钟生成基础Mapper，避免手写错误。
5.2 用数据字典扫描SQL注入风险点：VARCHAR字段的长度校验SQL
所有VARCHAR类型字段都是潜在注入点（尤其EXT_ATTR_*）。我们用数据字典生成校验SQL，检查输入值是否超长：
-- 生成所有 VARCHAR 字段的长度校验（以 ADDRESSBOOK 为例） SELECT CONCAT( 'SELECT ''', column_name, ''' AS field, LENGTH(', column_name, ') AS len, ''', SUBSTRING(data_type, 1, LENGTH(data_type)-1), ''' AS type FROM ADDRESSBOOK WHERE LENGTH(', column_name, ') > ', SUBSTRING_INDEX(SUBSTRING_INDEX(column_type, '(', -1), ')', 1), ' LIMIT 1;' ) AS check_sql FROM information_schema.columns WHERE table_name = 'ADDRESSBOOK' AND data_type = 'varchar';执行结果示例：
SELECT 'EXT_ATTR_1' AS field, LENGTH(EXT_ATTR_1) AS len, 'varchar(1024)' AS type FROM ADDRESSBOOK WHERE LENGTH(EXT_ATTR_1) > 1024 LIMIT 1;操作流程：将结果复制到MySQL执行，若返回记录，说明存在超长数据，需在应用层加
@Size(max=1024)校验。
5.3 构建低代码平台的元数据：从BBS_BOARD表生成动态表单配置
低代码平台需要知道“哪些字段可编辑、哪些只读、哪些是下拉”。我们用BBS_BOARD表的字段注释和类型，生成JSON配置：
{ "formName": "BBS_BOARD", "fields": [ { "name": "NAME", "label": "版块名称", "type": "text", "required": true, "maxLength": 1024 }, { "name": "DESCRIPTION", "label": "版块描述", "type": "textarea", "required": false, "maxLength": 800 }, { "name": "ANONYMOUS_FLAG", "label": "匿名讨论控制", "type": "select", "options": [ {"value": "0", "label": "允许匿名"}, {"value": "1", "label": "不允许匿名"} ], "required": true } ] }生成逻辑：
VARCHAR→text/textarea，SMALLINT且注释含“0-...1-...” →select，required由NOT_NULL标记决定。
价值：省去人工配置表单，上线即用。
从那以后我每次接到致远OA的定制需求，第一件事不是看代码，而是打开这份数据字典，用Ctrl+F搜关键词（如“同步”、“代理”、“考勤”），3分钟定位到目标表和字段。它让我少写了200+行试错SQL，也避免了3次因字段理解错误导致的线上故障。希望帮到你。
本文还有配套的精品资源，点击获取
