文书查 · 全量裁判文书检索
直连 近 1.6 亿 真实裁判文书全量库,实时查询。 每条给出案号,可到中国裁判文书网自行核对;原文直链目前系统性为空(见下方口径说明)。← 平台首页→ 案件大数据✦ AI 助手
数据来源与检索口径说明
检索范围:覆盖 近 1.6 亿 篇公开裁判文书全量库; 如需按案由/地域/年份看整体分布,请前往案件大数据。
原文溯源:结果不含中国裁判文书网原文直链 —— 上游 source_url 字段系统性为空 (2026-07-30 实测本站三条检索线合计 189/189 条为空; 2026-07-29 免费端点 302/302 条为空),成因是入库 doc_id 不是裁判文书网原始 docId, 无从派生真链,硬拼一个打不开的链接比留空更糟。核对原文请用案号: 逐条结果、导出 CSV 与复制清单均带案号,到 中国裁判文书网 ↗ 按案号检索。⚠️ 「按案号检索即可」这句,我们从来没验过它走不走得通,而且用 HTTP 验不出来:2026-08-22 现网实打该站的案号检索页(URL 上用 `s21=` 挂案号)共 6 组 —— 其中两个真案号直接取自本站检索结果、一个编造案号、一串垃圾、三个雪人字符,以及一个空案号,6 组全部返 200 / 14,179 字节 / `text/html`,响应体 md5 逐字节相同(`504af898bd320c6549ab0b06a44337b3`)。落点是 JS 单页应用,案号要到浏览器里才发给后端(页面外壳去掉脚本后可见文字仅 151 字,只有「登录/注册/搜索」这类导航词,一行结果都没有) ⇒ 状态码零信息量,你写脚本批量核一批案号只会拿到「条条 200」。而且连该站自己出结果的那个接口也是 200 裹着拒绝:同日 `POST wenshu.court.gov.cn/website/parse/rest.q4w`、不带登录凭证的程序化调用当场被拒,返回的仍是 HTTP 200(158 字节 `application/json`):`{"code":9,"success":false,"description":"没有权限请求接口"}`。两条加起来:朴素的 `res.ok` / 看状态码这两种自动核验,在这条路径上一定是假绿。但请别把这段读成「按案号回核走不通」 —— 恰恰相反,该站本身是通的(同日首页 200 / 22,309 字节),我们没有任何证据说人工在浏览器里按案号检索会失败,也没有在浏览器里人工试过。本段只钉住两件事:这条路径我们没验证过、而且它没法用状态码自动验证。要确认某一条,请人工打开该站检索(未登录时页面上就摆着「登录/注册」),别拿脚本的 200 当作核对通过。把「未验证」读成「已证伪」是另一种假话。但案号并非每条都有,且缺失「高度集中在婚姻家庭/人身类查询」,不是均匀分布:2026-07-30 免 key 实测 14 个关键词 654 条,合计 17/654(2.6%)缺案号,其中 q=离婚 9/50(18.0%)、利息 8.1%、工伤 6.0%、抚养 4.1%,而民间借贷/劳动争议/交通事故/买卖合同/继承/房屋买卖等 10 词均为 0% —— 按 2.6% 这个全站均值理解,会严重低估婚姻家庭检索里遇到它的概率。这类条目也退不回「案名 + 法院 + 裁判日期」核对:同批 17 条样本里,法院字段无一条是真法院名(0/17,写的是裁判文书网的不上网/不公开事由)、裁判日期仅 3/17 有值、原文直链 0/17,即 14/17 除案名外没有任何可核锚点。结果列表对这类条目会逐条标出「无案号」,不让它静默混在可回核的结果里。导出文件里的「原文链接」列因此整列为空,不是导出出错。
匹配口径:省份按文书登记口径筛选,案由是两层过滤,且本页在发出检索前会先把你填的案由改写成词干(剥掉通用后缀「纠纷/案件」——填「民间借贷纠纷」实际送出去的是「民间借贷」), 再在返回结果内按你填的原值二次校准。之所以要改写:后端对案由同样是分词匹配, 而「纠纷」二字在案由字段里近乎全命中 —— 实测直接送完整规范名时, 「离婚纠纷」「火星纠纷」(编造的案由)与「纠纷」三者返回的总篇数完全相同(均 188,553 篇), 限定词一条结果都没贡献;改送词干「离婚」则为 134,026 篇且本页 20/20 精准 (这组数字量于切片「关键词=离婚 且 省份=浙江省」, 只填案由时是另一个量级,见本段末)。因此顶部的总篇数是词干口径的,不是你所填案由的文书数 (两种写法实测差 1.41-4.24 倍),请以下方「案由分布」核对实际命中。「争议」结尾的案由要另外当心:改写只剥「纠纷/案件」、不剥「争议」 —— 实测填「人事争议」总篇数 167,325, 而返回的本页 20 条全是「劳动争议」、无一条人事争议(二次校准会把它们全部滤掉,于是总篇数很大而列表几乎为空),按词干「人事」查实际只有 7,420 篇 (这组量于「省份=广东省」,同见本段末)。关键词在文书全文内检索(标题、当事人、事实与本院认为等正文段落均可命中),年份按裁判(判决)年份过滤;法院是两层过滤:先由后端按法院名做分词匹配(会改变总篇数),再在本次返回结果内按法院名做精确细化 —— 法院名不区分是否带省级前缀(「通榆县人民法院」与「吉林省通榆县人民法院」视为同一家)。要紧的是后端那一层是「分词」而非精确匹配:「中级」「人民法院」这类通用词会各自匹配到 大量其他法院,故在部分写法上,法院名写得越完整总篇数反而越大(实测 q=利息&province=广东省 这一格:「深圳市」50.3 万 < 「深圳市中级人民法院」75.5 万;但这不是普遍规律,方向会反过来 —— 见下段反例), 且编造的法院名会继承通用词的结果(「火星人民法院」与「人民法院」返回完全相同的 264 万条)。因此顶部的总篇数不等于该法院的文书数——实测 293 条样本里真属所填法院的仅 5.8%。 建议只填不含省名的地名短词(如「深圳」),并以下方列表的「审理法院分布」核对实际命中,不要拿总篇数当作该法院的案件量引用(⚠️ 但「核对审理法院分布」这条补救有一格失灵 —— 见下方「编造的法院名可以三项判据全部读起来正常」那一段,那里给了唯一真能分辨的那一枪)。
上面那组数字是「带条件」的,别直接套到你这一页:「188,553 / 134,026 / 差 1.41-4.24 倍」实测于切片 关键词=离婚 且 省份=浙江省,「167,325 / 7,420」实测于 省份=广东省(2026-08-20 原样重打,两组数字均未过期)。你若只填案由、不填关键词也不填省份(顶部一键热门案由就是这么打的),同一组量级完全不同 —— 2026-08-20 实测:「离婚纠纷」「火星纠纷」「纠纷」三者仍完全相同,但是 28,673,899 篇(不是 188,553),本页 0/20 属离婚族;改送词干「离婚」是 2,762,644 篇(不是 134,026),本页 20/20 属离婚族。两种写法之比因此是 10.38 倍,不是 1.41 倍 —— 屏幕上那个区间的低端低估了约 7 倍。低端那个 1.41 是被关键词造出来的:那一格里「关键词=离婚」早就把池子筛过一遍了,实测该切片下 cause=离婚纠纷 与 cause=纠纷 首页文书序列逐位相同、首页 17/20 真属离婚纠纷 —— 那 17 条是关键词的功劳不是案由的;关键词一拿掉,同一对写法本页就是 0/20。不是整段都变了(同批对照):民间借贷 3.01 → 3.06 倍、买卖合同 4.24 → 4.33 倍几乎不动,因为那两格本就是无关键词/弱关键词量的,只有带强关键词的那一格会塌。(2026-08-21 订正上面那个 4.33:它的全称侧当时抄的是「纠纷」桶那个 28,673,899,而只填「买卖合同纠纷」实测是 36,565,787、词干「买卖合同」6,621,749 ⇒ 真比值 5.52 倍,不是 4.33;根因是信了「全称都塌成同一个数」那条规律,而它对带「合同」的案由名不成立,详见下段分档。)「争议」那组同理:只填案由时「人事争议」1,998,039 篇(不是 167,325)、词干「人事」64,416 篇(不是 7,420),比值 31.0 倍(不是 22.5 倍),而首页形态与上面所述一致(人事争议本页 20/20 是「劳动争议」、词干侧 20/20 真属人事族)——即上面那些结构性结论全部成立,塌掉的只是量级。⇒ 没填关键词时,别拿「1.41-4.24 倍」去反推顶部的总篇数,一律以下方「案由分布」核对实际命中。
「案由全称 ≈ 只按『纠纷』二字过滤」不是普遍规律,塌进哪个桶取决于案由名里的通用词(2026-08-21 实测,只填案由、不带关键词也不带省份,每格复打两次 total 与首页文书序列逐位相同):①「纠纷」桶 28,673,899 篇 —— 离婚纠纷、火星纠纷(编造的)、纠纷 三者 total 与首页序列完全相同;民间借贷纠纷 28,681,478、信用卡纠纷 28,741,678、机动车交通事故责任纠纷 29,045,691 首页序列同上、彼此差 ≤1.3%。②案由名里带「合同」的,桶比「纠纷」还大 27%-35% —— 买卖合同纠纷 36,565,787、借款合同纠纷 36,508,097、物业服务合同纠纷 36,508,096、金融借款合同纠纷 36,583,305、劳动合同纠纷 38,567,940。③案由名里带「财产」的,反而只有「纠纷」桶的 0.85% —— 离婚后财产纠纷 244,708、婚约财产纠纷 243,259(两者首页 20 条逐条相同)。④「争议」结尾的塌进另一个桶 —— 人事争议 1,998,039 与 争议 完全相同,而它与「纠纷」桶差 14.35 倍;劳动争议 2,403,164 又比「争议」桶大 20.3%。⇒ 按「≈纠纷桶」去估该案由的案件量,错的方向和倍数都随你怎么写案由名:带「合同」的低估 27%-35%、带「财产」的高估约 117 倍、「争议」结尾的高估约 14 倍。而词干侧是能与预聚合权威数对上账的:词干「买卖合同」6,621,749 与 /api/analytics?dim=cause 的「买卖合同纠纷 6,621,749」逐位相同,词干「民间借贷」9,374,165 与预聚合「民间借贷纠纷」9,322,422 差 0.55% —— 这是上面「建议改送词干」那句的正面证据(此前只说过词干「更真」,没给过权威对照)。上游为什么这么分桶,本站不猜:既有比「纠纷」桶大的、也有小两个数量级的,query 构造在数据侧、本站看不到,只报实测。
补:上面①那句「写得越完整结果越多」只在部分写法上成立,方向会反过来(2026-08-21 实测,与①同一格 q=利息&province=广东省):㈠同一个「中级」,两个相反的结果 —— 加在「深圳市」上零贡献(深圳市 502,789 → 深圳市中级 502,789,total 逐位相同),加在「人民法院」上却砍掉九成(人民法院 2,641,148 → 中级人民法院 292,866);㈡补全方向反过来就跌 —— 从 court=人民法院 2,641,148 补成 court=深圳市中级人民法院 754,801,名字写得更完整而总数降 3.5 倍 —— 这两个数,上面①和②各自就印着一个;㈢通用词尾之间也差两个数量级 —— court=法院 20,217 vs court=人民法院 2,641,148,差 130 倍;㈣真正在动的是那个通用词,不是「完整度」 —— court=深圳 只有 7,094,多一个「市」字就跳到 502,789(涨 70.9 倍)。⇒ 想靠「多写/少写几个字」把范围收宽收窄,方向不可预测,请以 total 与页内分布判断、并在返回结果内按法院精确核对;(本段每格当日只打了一次 —— 检索线免费额度 30 次/天按出口 IP 计,已用尽;其中 深圳市 502,789 / 法院 20,217 / 火星 0 与三周前 07-31 的登记逐位相同,可作对账。另:「深圳市 与 深圳市中级 total 相同」只验了 total,未验首页文书序列,故不称其为同一结果集。【2026-08-21 第 614 发:上面这两句诚实标注已兑现,双双撤回,原文不删只作对照】⑴「30 次/天按出口 IP 计」写窄了 —— 那只在不带设备标识的裸调用上成立;带 `x-wsc-did` 时出口 IP 桶上限是 360 次/天(本站自己的 `_meta.free_quota.caliber` 里就写着这一条),故「已用尽」是裸调用自设的墙,不是当天真没额度了;第 614 发据此在同一天把本段与下一段共 11 格各复打两次,20/20 逐位相同。⑵ 首页序列已补验:深圳市 与 深圳市中级 的首页 20 条 doc_id 序列 sha 逐位相同(`2f5cb8cdd0100c6a`,两打),故它们是同一个结果集,「中级」这两个字在这一格是被整体丢弃、而不只是「贡献为 0」。)
补二:上面那句「请以 total 与页内分布判断,勿凭首页」在最坏的一格失灵 —— 编造的法院名可以三项判据全部读起来正常(2026-08-21 第 614 发实测,切片 q=离婚&province=浙江省,每格各打两次、total 与首页 20 条 doc_id 序列 20/20 逐位相同):㈠ 一个不存在的法院,返回的就是「没筛」 —— court=火星人民法院 → 265,509,而同条件不填 court 是 282,126(它是基线的 94.1%,只差 5.9%,读起来完全像筛过了);且首页 20 条 doc_id 序列与「不填 court」逐位相同(sha `918bbce83b7cbc82`),页内分布自然也相同。court=人民法院 的三项数字与它完全一致(265,509 / 同一个 sha)。⇒ total 正常、首页正常、页内分布正常 —— 本段推荐的那两条判据在这一格都读不出「这个过滤器等于没填」;㈡ 真能分辨的只有一条 —— 拿同一组条件不填 court 再打一枪,比 total 与首页 doc_id 序列:一样(或只差几个百分点且首页逐位相同)就是没筛到,别再往下引用;⚠️ 但这一枪有一格打不出来 —— 当 court 是唯一条件(不填关键词/省份/案由,即从文书详情页点法院标签走的那条路)时,「不填 court」的那一枪会被本端点整份拒掉(`ok:false`「请至少填写一个检索条件」),没有基线可比;那一格的实测见本段末尾的「补三」;㈢ 编造名还能比真名更多 —— court=中级人民法院 15,108,而 court=火星市中级人民法院 20,822(多 37.8%);court=火星法院 72 ≡ court=火星 0 之外的那个词尾 court=法院 72(首页序列亦逐位相同);㈣ 上一段㈢那个「130 倍」是切片 A 的值,不是常数 —— 同一对 court=法院 vs court=人民法院,切片 A(q=利息&province=广东省)差 130 倍(20,217 vs 2,641,148),本切片差 3,688 倍(72 vs 265,509),两格之间又差 28 倍,请勿搬用;㈤ 上一段那条「中级被整体丢弃」换一格照样成立 —— 杭州市 34,832 ≡ 杭州市中级 34,832,首页 20 条 doc_id 序列 sha 逐位相同(`76fa3bca7d1336ec`),即与「深圳市 ≡ 深圳市中级」同型,不是单格偶然。(机理不猜:court=火星 单独打是 0、说明「火星」是有效词,接在「人民法院」后却整个不起作用,而「火星市」接在「中级人民法院」前又起作用(15,108 → 20,822)—— 三条同时成立,单纯 token OR 解释不了,query 构造在 .237/ES 侧、本仓看不到,故只报实测。)
补三:上面「不填 court 再打一枪做对照」这条唯一判据,在「court 是唯一条件」那一格打不出来 —— 而那正是从文书详情页点法院标签走的那条路(2026-08-21 第 615 发实测,切片=只填 court、不填关键词/省份/案由,每格各打两次、16 格 34 打,total 与首页 20 条 doc_id 序列全部逐位相同):㈠ 基线不存在 —— 什么条件都不填时本端点直接返 `ok:false`「请至少填写一个检索条件」,不是返回 0 条而是整份请求被拒,故「同条件不填 court 比一比」在这一格不可执行;㈡ 真法院名返回的就是整个库,且与编造名同一份 —— court=广州市天河区人民法院(真法院)134,228,823、court=人民法院 133,913,791、court=火星人民法院(编造)133,913,791,三者首页 20 条 doc_id 序列逐位相同(sha `ba5c379c49a587a0`),且首页真属该院的是 0/20;作量级参照,本站 /api/analytics?dim=province 的 30 个省桶之和是 137,531,382,即这批数≈全库的 97.4%–97.6%(两个数走不同上游,只作量级参照);㈢ 三家不同法院同一个首页 —— court=深圳市中级人民法院 16,463,002、court=杭州市中级人民法院 16,444,457、court=中级人民法院 15,072,516,首页 sha 同为 `c53aa5ed3624e6e3`、真属所填法院同为 0/20;编造的 court=火星市中级人民法院 16,593,012 比真的「中级人民法院」还多 10.1%;court=法院 1,015,179 ≡ court=火星法院 1,015,179(sha `0db0ca9f24421dca`),而 court=火星 单打是 0;倍率照旧只是本格的观测 —— court=深圳 16,514 → court=深圳市 1,601,743,只多一个「市」字涨 97.0 倍,而切片 A(q=利息&province=广东省)同一对是 70.9 倍,别当常数搬用;㈣ 本格多出一种「读 total 会以为筛过了」的形态 —— court=深圳市 1,601,743 → court=深圳市中级 1,609,183,total 不再相同(多 7,440 = +0.46%)而首页序列仍逐位相同(sha `ebb17fd3c79b4b0b`);这与上面两段那种「total 逐位相同」不同型,按 total 判会读成「这两个字筛掉了一点东西」;㈤ 站内那条路已就地修掉 —— 文书详情页的「审理法院」标签此前只发 `court=<法院全称>`,本发起另加 `q=<同一个法院名>`(与第 314 发对 /analytics 法院维下钻的处置同一个单一来源):实测首页精确命中 深圳市中级人民法院 0/20 → 20/20、广州市天河区人民法院 0/20 → 6/18;㈥ 但 total 没被修好,也修不了 —— 加 q 之后 total 仍是 OR 口径(深圳市中级人民法院 15,689,134、广州市天河区人民法院 117,913,630),改善的是「这一页是不是这家法院的文书」,不是总篇数;真·按法院精确检索需上游做 keyword/短语匹配,属 .237/ES 侧。(机理照旧不猜:court=火星 单打 0、court=法 单打 399、court=人民 单打 4,712,而 court=人民法院 是 133,913,791 —— 单纯 token OR 或单字切分都解释不了这四条同时成立。)
使用提示:数据来源于公开裁判文书,受文书上网范围与公开比例影响, 单次检索返回结果有数量上限,结果内的统计与分布仅反映本次返回样本; 内容仅供研究与参考,不构成法律意见。
全量 近 1.6 亿裁判文书类案检索 · 关键词为文书全文检索(正文命中会展示命中摘要) · 建议配合省份/案由缩小范围以提速。
常见问题
类案检索覆盖多少裁判文书?支持哪些检索维度?
覆盖全量公开裁判文书库(近 1.6 亿篇),支持按关键词(命中文书全文并高亮)、省份、案由、法院、年份区间检索,可叠加多个条件;结果内可再做二次检索与文书类型、审判程序等结果内筛选,命中条目可内联展开裁判理由与裁判结果。
检索到的都是判决书吗?
不是。本库是「裁判文书」库,除判决书外还包含裁定书、调解书、通知书、决定书、令、公告等。实测同一检索条件下,能被标成判决书的通常只占四到七成,因此「命中 N 篇」不等于「N 份判决」。但这个四到七成要按「下限」读,不是判决书的真实占比:文书类型由上游按案名判定,案名没写「判决书」的一律落进「其他」兜底桶,该桶占同一检索条件下的 3%-19%(2026-07-31 实测 q=离婚 18.7%、q=利息 3.6%),里面的文书类型未知,而抽样显示其中相当一部分正文自称判决书(279 篇其他桶样本中,正文可判的 159 篇里 83 篇是判决书;一个能一次翻完的 88 篇窄切片里,6 篇其他桶文书正文首行全部自称判决书)。如只需判决书,请在左栏「文书类型」筛选「判决书」后重新检索,页面与导出会按判决书口径给出计数;需要留意的是该筛选覆盖不到「其他」桶那批未归类文书(任何文书类型取值都选不中它们),故按它统计出的判决数同样偏保守。
每条结果都能看到文书全文和原文链接吗?
多数条目可内联展开文书正文(判决理由、裁判结果等);但「缺正文」的比例由检索方式决定,不是「少量早期入库条目」:带关键词检索(相关度排序)会把一批很短的条目顶到前面(标题形如「利息计算说明」「3、李红伟有利息拟稿」),它们的正文本就为空。本次检索的实时比例请读免 key 响应顶层 full_text_page(missing / counted / pct),别拿下面这批历史抽样值当定值:2026-07-29 实测(pageSize=40,免 key)q=利息 首页 21/28≈75%、q=违约金 27/39≈69% 缺正文,而 q=商标侵权、q=工资 首页均 0/40,不带关键词(按裁判日期倒序)5 省各 40 条合计 0/200;深页不必然变好 —— q=利息 第 5 页降到 2/37≈5%,而 q=违约金 第 5 页反而是 31/40≈78%(2026-08-17 复测这批数逐位相同)。结构化字段同理并且更狠:同一批实测里 q=工资 首页案由 40/40 全空,而不带关键词的三省各 40 条合计 0/120 全部有案由(缺失口径见下一问「未标注」)。「入库早晚」本站从未测过,页面也没有任何字段能让你自证它,而唯一能看到的日期字段指向相反方向:2026-08-17 实测 q=利息 首页缺正文那 21 条的裁判年份是 2019(12 条)/2020(9 条),有正文的 7 条落在 2016-2018 与无日期。页面「仅看有全文」可过滤出可展开的条目,展开视图对缺正文的条目会给出案号供核对。原文链接则要说清楚:裁判文书网原文直链目前系统性为空,不是「部分条目暂缺」——2026-07-30 实测本站三条检索线合计 189/189 条为空,2026-07-29 免费端点 302/302 条为空,成因是入库 doc_id 不是裁判文书网原始 docId,无从派生真实链接,而硬拼一个打不开的链接比留空更糟。核对原文请凭案号到中国裁判文书网自行检索。但案号并非每条都有,且缺失高度集中在婚姻家庭/人身类查询,不是均匀分布:2026-07-30 免 key 实测 14 个关键词 654 条,合计 17/654(2.6%)缺案号,其中 q=离婚 9/50(18.0%)、利息 8.1%、工伤 6.0%、抚养 4.1%,而民间借贷/劳动争议/交通事故/买卖合同/继承/房屋买卖等 10 词均为 0%,按 2.6% 这个全站均值理解会低估婚姻家庭检索里遇到它的概率。这类条目也退不回「案名、法院、裁判日期」核对:同批 17 条样本里法院字段无一条是真法院名(0/17,写的是裁判文书网的不上网/不公开事由)、裁判日期仅 3/17 有值、原文直链 0/17,即 14/17 除案名外没有任何可核锚点;结果列表已对这类条目逐条标出「无案号」。导出 CSV 里的「原文链接」列因此整列为空,不是导出出错。⚠️ 「按案号检索即可」这句,我们从来没验过它走不走得通,而且用 HTTP 验不出来:2026-08-22 现网实打该站的案号检索页(URL 上用 `s21=` 挂案号)共 6 组 —— 其中两个真案号直接取自本站检索结果、一个编造案号、一串垃圾、三个雪人字符,以及一个空案号,6 组全部返 200 / 14,179 字节 / `text/html`,响应体 md5 逐字节相同(`504af898bd320c6549ab0b06a44337b3`)。落点是 JS 单页应用,案号要到浏览器里才发给后端(页面外壳去掉脚本后可见文字仅 151 字,只有「登录/注册/搜索」这类导航词,一行结果都没有) ⇒ 状态码零信息量,你写脚本批量核一批案号只会拿到「条条 200」。而且连该站自己出结果的那个接口也是 200 裹着拒绝:同日 `POST wenshu.court.gov.cn/website/parse/rest.q4w`、不带登录凭证的程序化调用当场被拒,返回的仍是 HTTP 200(158 字节 `application/json`):`{"code":9,"success":false,"description":"没有权限请求接口"}`。两条加起来:朴素的 `res.ok` / 看状态码这两种自动核验,在这条路径上一定是假绿。但请别把这段读成「按案号回核走不通」 —— 恰恰相反,该站本身是通的(同日首页 200 / 22,309 字节),我们没有任何证据说人工在浏览器里按案号检索会失败,也没有在浏览器里人工试过。本段只钉住两件事:这条路径我们没验证过、而且它没法用状态码自动验证。要确认某一条,请人工打开该站检索(未登录时页面上就摆着「登录/注册」),别拿脚本的 200 当作核对通过。把「未验证」读成「已证伪」是另一种假话。
结果里的案由、法院等字段为什么有的显示「未标注」?
案由、法院等取自文书结构化字段,上游存在字段缺失或取值非规范的情况(例如「法院」字段填的是裁判文书网的不上网/不公开事由)。本页对这类条目统一以「未标注」口径接住,不做猜测式补全——错误的案由比缺失的案由更容易误导核对,故按字段实际取值如实呈现。
检索结果能导出吗?导出内容包含什么?
可以。支持导出结果清单 CSV、多篇对比表、文书全文合集 TXT(与页面按钮/下载文件名一致),以及复制清单。导出文件会带上文书类型占比、法院字段异常等口径说明,并按当前筛选(如「仅看有全文」「文书类型=判决书」)一致输出,避免脱离页面口径单独解读。
检索结果能等同于全部实际案件吗?
不能。数据来源于公开裁判文书,受文书上网范围与公开比例影响,检索结果反映的是已公开样本,不等于全部实际案件;命中数量为已公开且已入库条目的计数。结果仅供研究与参考,不构成法律意见。