GDHG 股本与可售压力账本

每次反向合股时授权股怎么变（EthanClaude01 回查 · 2026-09-17，GDHGClaude 代补，不改本轨判断）

三次已落地的反拆，授权股都按同一比例同步缩了（授权总额按面值计不变）。但每一次都是同一场股东会先把授权扩大，再并股：2024 年先把 B 类授权从 2 亿扩到 3 亿，2025-05 先扩到原来的 20 倍，2025-08 先扩到原来的 30 倍。所以并股后「还能发多少新股」相对在外股反而大增，约 8.6 倍 → 约 549 倍 → 约 1,300 倍；2026-04 减面值时 A 授权定为 30 亿，同时在外股增到 5,942 万，现在约 49.5 倍。这是逐次查一手件的结果，不是按公司惯例或别家类推。

比值是否有定义：GDHG 是开曼有限公司，授权股本有上限、有面值（现为每股 0.00001 美元，章程第 8 条），不是 unlimited / 无面值，「未发行授权 ÷ 在外股」这个比值有定义。

共用一手资料的检索基底（基底回查 · 2026-09-18，GDHGClaude 代补，不改本轨判断）

四个数分开写：应有 155 份 / 实际取回 155 份 / 可全文检索 154 份 / 未转文本附件 315 个（全部为图片）。① 应有份数 155：2026-09-18 用 SEC submissions JSON 复核，recent 数组 155 条，filings.files[] 分片为空（没有更早分片），也没有 9-11 之后的新申报。② 实际取回 155：逐份用 EDGAR 每份的文件清单（index.json）与本机比对，155 份都有完整提交文本，缺失文档 0 个；EDGAR 列出的 1,073 个文档全部在盘，0 字节文件 0 个、小于 200 字节的残件 0 个（份数与非空份数一致，不是「下载器返回了空文件」那种假完整）。还做了两道「非空也可能是空壳」的检查：内容指纹全库扫描——搜「Undeclared Automated Tool」「Request Rate Threshold」这类 SEC 限流提示页字样，命中 0 处；（补注 2026-09-18：用的是整句指纹并带词边界；特意不用「rate limit」这类宽口径子串——在 GDHG 上宽口径会命中十几份真文件，匹配到的其实是开曼章程里的「body corporate limited by shares」。因为命中 0 处，本次没有删除或重下任何文件。）【方法描述更正 2026-09-18 深夜】上面这句「整句指纹并带词边界」不足以照抄：词边界挡不住连字符断词（\brate limit\b 会命中「sepa-rate Limit-ed」），也挡不住标签与换行断句。定版是 7 步管线，指纹与待搜文本走同一个函数：①剥 script/style 内容 →②剥 HTML 标签 →③实体还原（ ）→④NFKC →④a 显式去软连字符、④b 显式折破折号（实测 NFKC 两样都不做：U+2013／U+2014／U+00AD／U+2011／U+2212 原样保留，只折全角 U+FF0D，所以不能把这两步的功劳记给 NFKC）→⑤连续空白折单空格 →⑥转小写 →⑦在前六步之后再取一份「只留字母数字」的变体，与第⑥步结果取并集（剥标签时补空格会把 Unde<span>clared</span> 变成断词，只有第⑦步救得回；⑦不可省，也不可用来替代剥标签）。第⑦步只用于整句指纹，短词一律不用。按定版重扫本票一手语料：遍历 2,697 个文件（451 MB），解析出值 2,697、取件失败 0、解析失败 0，命中仍为 0，四个数不变。另记两条：命中不等于结论（相邻单元格会被粘成整句，须回看原文再决定），件号一律只搜数字位。逐份字节比对——用 EDGAR 每份文件清单里的字节数比对 1,085 个文档，11 个比记录小 89–165 字节，逐一打开确认是本机存的是去掉 SGML 外壳的正文，文档结尾完整、都不是提示页。③ 可全文检索 154：155 份里有 1 份正文只有图片——2023-03-03 的自由写作招股书（正文可取出的字只有 66 字节，实体内容是 26 张整页图）。另有 14 份是 XML 表单（SEC 生效通知 5 份、内部人首次持股申报 6 份、拟出售通知 3 份），正文字数很少，但字段已逐项解析。④ 未转文本 315：全部为图片附件，见下。155 份共 1,065 个内容文档：HTML 正文与附件 642、XBRL 与表单 XML 64、分类标准 6、XBRL 压缩包 8、阅读器附件 24、PDF 14、图片 315。

PDF（14 个）：13 封 SEC 意见信与 1 份交易所上市证明。2026-09-18 已全部转成文本，没有只扫描、取不出字的。当初做页面时这 14 个 PDF 不在本席的检索文本里；重新检索后未发现与页面结论冲突的内容。同日还补转了 3 份 2022 年公司回函（2026-09-17 才补拉，当时也不在文本库里；正文分别约 26,000、9,600、3,900 字节，内容与页面里的 SEC 审阅叙述一致）。

图片（315 个，未做文字识别）：2023 年 IPO 投资者演示整页图 104（6-K 2023-04-17 的 52 页与两份自由写作招股书各 26 页）、正文插图与签字页 103、律师意见与同意函扫描 47、logo 28、公司结构图 22、股东会委托书卡片 11。已逐张核对的是有实质内容的那几类：2026-05-19 的新架构图（本席亲看，与页面描述一致：开曼 → Magic Golden Heaven BVI → 香港 → 福州、南平两家金嘉年华）、2026-08-31 招股书的三张结构图、2025-01-22 的委托书卡片（内容与同一份文件的 HTML 通知一致）。其余为演示文稿与签字、logo 类。【更正 2026-09-19（GDHGClaude 代补，不改本轨判断）：上面这段分类是推断，不是逐张核实】上面那六个分类数（104 / 103 / 47 / 28 / 22 / 11）不是逐张看图得出的，是按文件名形态与所属申报推的，按现有依据复现不出来，不应写成已核的分类。改以可复现的三档为准：连续编号页（*_0NN.jpg 这类）270 张、logo 28 张、其它命名 17 张，合计 315 张，分布在 48 份申报（按年：2023 年 169、2022 年 46、2024 年 42、2025 年 29、2026 年 29）。本席真正打开看过的是 6 张（占 1.9%）：2026-05-19 新架构图 1 张、2026-08-31 招股书结构图 3 张、2025-01-22 委托书卡片 2 张（页面原写「委托书卡片 11」，实际该份只有 2 张）。这三处的内容与页面描述一致这一点不变；其余 309 张只作了文件名层面的归类，没有逐张看过，「其余是演示文稿与签字、logo 类」是推断而非核实。「315 张未做文字识别、本页结论不含图片文字识别」这条范围声明不受影响。

本页「未发现 / 未见」的说法，按其自述范围为「所核 SEC 主文件与重大附件」。就共用的一手资料而言，该范围对应上述 155 份申报的可检索文本，不含 315 个图片附件的文字识别。

更正：文件层的两个口径要分开数（文件层口径更正 · 2026-09-18 晚，GDHGClaude 代补，不改本轨判断）

只加不删说明：上面那段基底说明里的文件层数字口径不清，下面逐条更正，原文一字未删。份数（155 份申报）的结论不受影响，缺件仍然是 0。

① 两个口径不能相减。「SEC 目录项数」与「整份提交件内的文档数」是两套数： R*.htm 这类 XBRL 渲染件在 SEC 目录里不算文档，但在整份提交件内部是以 TYPE=XML 计为一个 <DOCUMENT> 的 （本席在 20-F 0001213900-26-005908 上逐个看过：该份 86 个文档里有 62 个是 R*.htm，TYPE 全是 XML；Show.js、report.css、FilingSummary.xml 同样以 XML 计，MetaLinks.json 以 JSON 计）。 所以两个口径要分别标注，不要用「目录项数减去 index 与渲染件」去凑提交件内的文档数。

② SEC 目录口径（本票 155 份合计 1,245 项，已剔除三类目录页）： 真内容文档 707（HTML 正文与附件 303、图片 315、XBRL 与表单 XML 56、PDF 14、纯文本件 13、分类标准 XSD 6）、 XBRL 渲染件 R*.htm 339、渲染与清单件 32（Show.js 8、report.css 8、MetaLinks.json 8、FilingSummary.xml 8）、 XBRL 压缩包 8、Financial_Report.xlsx 4、整份提交件 155。

③ 整份提交件口径：155 份提交件内共 1,090 个 <DOCUMENT>。

④ 对上面原文数字的更正。原文写「155 份共 1,065 个内容文档：HTML 正文与附件 642、XBRL 与表单 XML 64、分类标准 6、XBRL 压缩包 8、阅读器附件 24、PDF 14、图片 315」，三处要改： （a）1,065 与其后分项之和不符，分项相加是 1,073； （b）1,073 这个数是「目录项减去三类目录页与整份提交件」，里面含 339 个 R*.htm 与 32 个渲染清单件，不应叫「内容文档」，真内容文档是 707； （c）「HTML 正文与附件 642」＝真 HTML 文档 303 ＋ R*.htm 渲染件 339；「阅读器附件 24」漏了 FilingSummary.xml 8 件（它被算进了「XBRL 与表单 XML 64」里），按渲染清单件应为 32。

⑤ 漏计的一类已补上：13 份 SEC 意见信在 EDGAR 目录里另有纯文本孪生件 filename2.txt。原脚本把所有 .txt 一律当成整份提交件排除，所以这 13 件既没计数也没单独下载。 复核结果：13 件全部可取（8 件磁盘上有单件，5 件在整份提交件内），正文 886–17,950 字节，内容与同一封信的 PDF 一致。

⑥ 字节比对的完整口径。原文写「比对 1,085 个文档，11 个偏小」，完整口径应为 1,245 个非目录页项： 字节完全一致 1,061 项、本地偏小 24 项、本地偏大 155 项（即整份提交件，EDGAR 目录里这一项的 size 记为 0）、磁盘无单件 5 项（即上面那 5 份 filename2.txt，都在提交件内）。 24 个偏小项已逐项复核：本地单件与整份提交件内同名文档逐字符一致、结尾完整（差的 89–219 字节是 EDGAR 目录把 SGML 外壳算进了大小），异常 0 项。

⑦ PDF 单独当一关（份数对账与非空核查都拦不住坏 PDF）。本票 14 个 PDF：魔数全部是 %PDF-，全部抽出文本（616–15,622 字符，最短的是一页纸的「不予审阅」函），没有出现几十到一百多字节的坏件。 只有 PDF 的提交包正好是这 14 份，其中 13 份另有上面说的纯文本孪生件，文本可得性是双保险。

⑧ 缺件结论仍是 0。逐份用提交件内的 <FILENAME> 清单与 SEC 目录比对：目录列出的文档在提交件内一件不缺；本席这轮没有报过、也不存在「缺文件 / 补下 N 个文件」的情形。

⑨ 检索写法两条。（a）件号只搜数字部分，对连字符、短破折号（–）、长破折号（—）一律免疫：页面引用的 333-279942、333-295337 已按「279942」「295337」复核，语料分别命中 143、53 个文件。 （b）同一表格有两种写法：GDHG 的持股申报在 EDGAR 上 SC 13G 与 SCHEDULE 13G 并存（13 系列合计 22 份：SC 13G 5、SCHEDULE 13G 8、SC 13G/A 4、SCHEDULE 13G/A 2、SC 13D 2、SC 13D/A 1）。 按两种写法重新核过，本页「2024-08-02 之后 YITONG / Gong 没有再交 13D/A」仍然成立；2024-08-16 那份 SC 13D 是另一位申报人 Gan Xiaochun（45,000,000 股、20.8%，0001213900-24-070301），本页已另有覆盖。

⑩ 空结果不计进「已核」。本票只有两处结论用过 EDGAR 全文检索（「Hearings Panel」与「A.G.P.」），两次都有返回命中，不是零结果；其余「未见 / 找不到」都基于 155 份的可检索文本，不依赖任何返回 0 的查询。

两个口径的对照表，与受理时刻怎么读（口径补注 · 2026-09-19，GDHGClaude 代补，不改本轨判断）

这一节不更正任何数字，只把上面已经写过的口径列清楚，方便照做的人不踩坑。

一、文件层的两套数，分别标注、不相减

同一批文件在两个口径下数出不同的值是正常的，不能用一个减另一个：R*.htm 在 SEC 目录里不算文档，在提交件内却是文档。

二、受理时刻（判盘前／盘中／盘后）该读哪一份

回落顺序是三级，不是两级：① <accession>-index-headers.html 里的 <ACCEPTANCE-DATETIME>（美东、14 位、无时区标记）→ ② 取不到就往上游走一层，读整份提交件 .txt 的报头（同一条正则通吃）→ ③ 实在没有才用 submissions API 的值，且必须标注来源、只当参考。 本票 155 份里：①在盘 140 份，其余 15 份（早期 CORRESP、UPLOAD、2022 年 F-1/DRS）走②拿到值；解析失败 0，没有一件需要走③。

判读规则：解析受理时刻得 0 时，先别下「该件缺值」的结论——先确认自己打的是哪一份报头、有没有做实体还原、有没有往上游取整份提交件。「缺值」和「打错位置」在输出上完全一样，混淆了就会把自己的解析 bug 记成数据源缺陷。

三个容易踩的坑，都是本机实测： ① 这个文件里其实有两份报头——顶部 HTML 注释里是原样标签的那份，<PRE> 段是同一报头的 HTML 转义渲染。 脚本若只解析 <PRE> 段又不做实体还原，本票 140 份会全部取不到值（100% 假空），而那个 0 看起来就像「这份没有受理时刻」。 这个失效是必然而不是偶发（多家实测都是 100%），所以更危险：偶发的会被当噪声查一查，必然的反而容易被当成「这个源本来就没有这个字段」。 ② 不要说「与整份提交件逐字节相同」：首行 <SEC-DOCUMENT> 指向的文件名本来就不同。准确的说法是受理时刻那一行一字不差。 ③ 不要写死行数：解转义后连续相同的行数随申报人条目多少浮动，本票实测 31–58 行（众数 37；6-K 36–37、UPLOAD 31–33、Form 3 48–50、SCHEDULE 13G 57）。 另：submissions API 的 acceptanceDateTime 只作参考、不作判据（本票与报头的时差为 +4h 97 份、+5h 58 份，未见 +0h 的坏值）。