1. DataGrip 列冻结后行错位问题到底出在哪如果你正在用 DataGrip 或 IDEA 的 DataGrid Column Sidebar 插件并且已经体验过列冻结功能那你大概率遇到过这个场景把主键 id 固定在左侧水平滚动查看后面几十个字段结果一缩放字体固定列的行高和主表对不上了越往下滚错位越明显。这不是插件逻辑写错了而是 JScrollPane 的 rowHeaderView 机制本身有一个容易被忽略的同步盲区。DataGrid Column Sidebar 解决的是 DataGrip 原生不支持列冻结、字段多了找不到列的问题。它通过反射拿到 DataGrid 内部的 JTable 和 JScrollPane创建一个只包含冻结列的代理 JTable把它设为 JScrollPane 的 rowHeaderView。固定列的表头放在 UPPER_LEFT_CORNER 位置和主表列头对齐。听起来很合理但问题出在主表的 rowHeight 和 font 变化时rowHeaderView 不会自动跟着变。你缩放字体主表行高变了固定列还是旧行高于是行错位。这篇要做的不是让 AI 直接连你的 DataGrip 或数据库而是先在本地把插件源码和错位日志整理好配一个走 TaoToken 通道的 Codex用它来对照 ColumnFreezeController 里 rowHeaderView 的行高同步逻辑把错位问题定位清楚。适合正在开发或调试 IntelliJ 平台插件、尤其是涉及 JTable/JScrollPane 自定义渲染的开发者。2. 前置准备TaoToken 给 Codex 供 Key 和 Base URL在开始排查之前先把 Codex 的接入通道配好。这里用 TaoToken 作为 Codex 的 API 通道它只负责提供 Key 和 Base URL不碰你的 DataGrip 或数据库连接。你可以先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册账号然后在控制台创建一个 API Key。创建 Key 的入口在控制台的 API Keys 页面直接访问 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 就能到。创建时给它起个容易认的名字比如 codex-datagrid-debug方便后面在 Codex 配置里对应上。拿到 Key 之后Codex 的 Base URL 填 https://taotoken.net/api这个地址不加任何 UTM 参数直接写就行。Key 用你刚创建的那一串。配置完成后Codex 的请求就会走 TaoToken 通道你可以在模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 先发一条测试消息确认通道是通的。这一步的关键是TaoToken 只给 Codex 供 Key 和 Base URL你的 DataGrip 连接、数据库密码、插件源码都不经过它。排查错位问题时你是在本地把源码和日志喂给 Codex让它帮你分析 ColumnFreezeController 的逻辑而不是让它去操作你的 IDE。3. 可复制配置Codex 接入与本地源码整理3.1 Codex 配置文件写法Codex 的配置通常放在用户目录下的配置文件中。以常见的 TOML 格式为例你可以这样写# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后在环境变量里设置 Key# Linux / macOS export TAOTOKEN_API_KEYsk-你的Key # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的Key如果你用的是其他客户端形态核心就两个参数Base URL 填 https://taotoken.net/apiAPI Key 填你创建的那串。不要在这两个值里加多余路径或参数。3.2 本地整理插件源码和错位日志在让 Codex 分析之前先把材料准备好。你需要从源码仓库拿到 ColumnFreezeController 相关代码重点看这几个方法// ColumnFreezeController 中与行高同步相关的关键逻辑 private fun syncRowHeight(mainTable: JTable, frozenTable: JTable) { frozenTable.rowHeight mainTable.rowHeight } private fun syncFont(mainTable: JTable, frozenTable: JTable) { frozenTable.font mainTable.font frozenTable.tableHeader.font mainTable.tableHeader.font }同时把错位日志整理成一个文本文件记录你操作时的现象缩放字体前后主表和固定列的 rowHeight 值、font 大小、滚动位置。比如[操作] 字体从 12 缩放到 14 [主表] rowHeight18 - 21, font12 - 14 [固定列] rowHeight18 - 18, font12 - 12 [现象] 固定列行高未变向下滚动第 5 行开始错位把源码片段和日志一起贴给 Codex让它对照分析。这样比直接问“为什么错位”要有效得多因为 Codex 能看到具体的属性变化数据。3.3 用 Codex 对照分析 rowHeaderView 同步逻辑在 Codex 里发这样的提示以下是 ColumnFreezeController 中 rowHeaderView 的实现片段和错位日志。 请分析主表 rowHeight 和 font 变化时frozenTable 的同步是否完整 是否存在监听器注册遗漏或属性传播断点Codex 会帮你逐行对照指出比如“你监听了 rowHeight 但没监听 font 的派生变化”“tableHeader 的 font 同步漏了”这类具体问题。实测下来这种带源码和日志的提问方式比泛泛描述现象要准得多。4. 验证请求确认 Codex 通道与排查结果4.1 验证 TaoToken 通道是否通配置完成后先在 Codex 里发一条简单请求确认通道正常# 如果 Codex 提供 CLI 形态 codex 用一句话说明 JScrollPane rowHeaderView 的作用或者在模型对话页面直接发消息。如果返回正常说明 Base URL 和 Key 都配对了。如果报 401检查 Key 是否复制完整如果报连接错误检查 Base URL 是否写成了 https://taotoken.net/api 而不是其他路径。4.2 验证错位排查结果把整理好的源码和日志发给 Codex 后你会得到一份分析。重点看它是否指出了这几个常见断点排查点正确做法常见遗漏rowHeight 同步监听主表 rowHeight 属性变化只设初始值不监听变化font 同步同时同步 tableHeader 的 font只同步表格 font漏表头监听器注册在 rowHeaderView 设置后注册设置前注册监听不到缩放事件监听 UI 缩放而非仅 font只监听 font漏 UI 缩放如果 Codex 指出你的 ColumnFreezeController 里syncFont方法没有同步tableHeader.font那这就是错位的直接原因。补上之后重新构建插件在 DataGrip 里缩放字体测试固定列和主表行高应该保持一致。4.3 重新构建并验证修改后重新构建插件# 在插件项目根目录 ./gradlew buildPlugin然后在 DataGrip 里重新安装插件打开一个有 50 列的查询结果固定 id 列缩放字体水平滚动。如果固定列行高跟着变且滚动到底部都不错位说明修复生效。5. 本篇常见错排查5.1 Codex 报 401 或 403先检查 Key 是否在环境变量里正确设置再确认 Base URL 是不是 https://taotoken.net/api。注意不要在这个地址后面加/v1或其他路径Codex 的 wire_api 配置会处理协议细节。如果还是不通去控制台确认 Key 是否被禁用或额度是否用完。5.2 固定列行高同步了但表头错位这是只同步了表格 font 没同步 tableHeader.font 的典型表现。JTable 的表格体和表头是分开渲染的缩放字体时两者都要同步。检查你的syncFont方法是否覆盖了frozenTable.tableHeader.font。5.3 切换查询 tab 后固定列消失DataGrid Column Sidebar 通过订阅DataGrid.ACTIVE_GRID_CHANGED_TOPIC来跟踪当前激活的网格。如果切换 tab 后固定列没恢复检查你的 DataGridTracker 是否在切换事件里重新绑定了 rowHeaderView。定时轮询兜底方案也要确认在数据加载完成后触发了刷新。5.4 缩放字体后错位但滚动一下又对齐这说明 rowHeight 同步了但渲染时机不对。JScrollPane 的 rowHeaderView 在滚动时会重新计算可见区域如果同步逻辑放在滚动事件之后就会出现“滚动一下才对”的现象。把同步逻辑放到属性变化监听器里而不是滚动监听里。5.5 固定列无法隐藏这是插件的设计约束已固定的列不允许隐藏需要先取消固定。如果你在 ColumnVisibilityController 里发现固定列的 checkbox 被禁用了这是预期行为不是 bug。排查错位问题时不用管这个。6. 继续用 Codex 排查插件问题的接入方式如果你还想继续用 Codex 对照分析其他插件逻辑比如列定位滚动的scrollRectToVisible调用时机、或者列可见性控制的ModelIndex.forColumn()构建可以保持当前的 TaoToken 通道配置不变。需要新 Key 时去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 创建接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 可以查到 Base URL 和参数的完整说明。如果你后面要长期做插件开发或 Agent 类的编码任务可以看看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合持续性的编码场景。单纯验证模型对话是否正常用模型对话页面就够了。排查接入类问题优先看 API Keys 和接入文档两个入口。把源码和日志整理清楚用 Codex 对照分析比盲目改代码要快得多。错位问题的根因往往就在那一两个没同步的属性上找到它改完重新构建问题就结了。