react-docgen-typescript是基于TypeScript编译器API的静态分析器，能从类型定义、JSDoc注释和符号声明中提取完整Prop结构，无需手写解析逻辑；它不依赖运行时泛型推导，因后者无法获取注释、默认值等语义信息。
直接用 react-docgen-typescript 就能从 TypeScript 类型定义里提取出完整的 Prop 结构，不需要手写解析逻辑或手动维护文档。它不是“元编程运行时工具”，而是基于 TypeScript 编译器 API 的静态分析器——这点必须分清，否则容易在项目里误用装饰器、typeof 或泛型推导去“动态生成文档”，结果既不可靠又难调试。
为什么不能靠泛型或类型工具（如 Pick、Partial）生成文档
TypeScript 的类型工具只在编译期起作用，无法读取 JSDoc 注释、默认值、是否 required、参数描述等语义信息。比如：
type ButtonProps = {
/** 点击后触发的回调 */
onClick?: () => void;
disabled?: boolean;
};
这段代码里 onClick 的 JSDoc 和可选性（?）能被 react-docgen-typescript 提取，但如果你只用 keyof ButtonProps 或 Required<buttonprops></buttonprops>，就拿不到注释、@default 标签、甚至无法区分 disabled: boolean 和 disabled?: boolean 的差异。
-
react-docgen-typescript调用的是ts.TypeChecker，能访问 AST 中的JsDocComment节点和符号（Symbol）的完整声明信息 - 泛型操作仅作用于类型系统，不触达源码文本层，也就无法还原开发者写的自然语言说明
- 试图用
typeof Component获取 props 类型会失败——函数组件没有运行时类型对象，typeof只返回function
如何让 react-docgen-typescript 正确识别 Props 接口
它依赖明确的类型绑定方式。以下写法会被识别，其他常见写法可能漏掉字段或注释：
使用 Scrapfly SDK（scrapfly-sdk）在 TypeScript 或 JavaScript 中进行网页抓取，用于用户请求抓取 URL、绕过反爬虫防护、渲染页面等场景。
- 函数组件第一参数显式标注接口：
const Button = ({ onClick, disabled }: ButtonProps) => { ... } - 使用
React.FC<buttonprops></buttonprops>类型断言（但注意：它会丢失defaultProps，推荐不用） - Props 类型单独导出，并在组件签名中引用：
export const Button: React.FC<buttonprops> = (props) => { ... }</buttonprops> - JSDoc 必须紧贴接口字段定义，且用标准标签：
/** @default false */ disabled?: boolean;
反例：用 any、unknown 或内联匿名类型（{ onClick?: () => void }）会导致字段完全不可见；用 interface 但未在组件中显式引用，也可能被跳过。
生成文档时容易忽略的三个硬性约束
即使配置正确，仍可能输出空文档或缺失字段。检查以下三点：
-
tsconfig.json中必须启用"compilerOptions": { "skipLibCheck": false, "allowSyntheticDefaultImports": true }，否则无法解析import * as React场景 - 组件文件不能是
.tsx但被exclude在 tsconfig 的include之外——RDTS 不会主动扫描未参与编译的文件 - 如果用了
forwardRef或memo，需额外配置shouldExtractLiteralValuesFromEnum和propFilter，否则默认会跳过高阶组件的 props
例如 forwardRef 组件要加这个配置项：resolver: require('react-docgen-typescript').default.resolver.findAllComponentDefinitions，否则只看到 ref 字段，看不到实际 props。
真正关键的不是“怎么写类型”，而是“怎么让类型信息连同注释一起被编译器 API 看到”。所有自动化文档生成都卡在这一步——没走通解析链路，后面再花哨的元编程技巧都只是空中楼阁。
