文书查是什么?数据从哪里来、覆盖多少?

数据来源

平台数据均来源于公开裁判文书。绝大多数结果给出案号,可按案号到中国裁判文书网自行核对; 少数条目缺案号(实测集中在婚姻家庭/人身类查询),详见下方原文溯源口径。

原文溯源口径(请先读)
结果不含中国裁判文书网原文直链:上游 source_url 字段系统性为空 —— 2026-07-30 实测两条不同的取数线(关键词检索线 6 词 224 条、省份浏览线 2 省 80 条)共 304 条结果,无一条带链接。成因是入库 doc_id 并非裁判文书网的原始 docId, 无从派生真实链接;硬拼一个打不开的假链接比留空更糟,故留空。
可行的回核路径是案号:按案号 + 法院 + 裁判日期到 中国裁判文书网 检索原文。案号亦非满值,且缺失不是均匀分布:关键词检索线上约 2.6% 的条目连案号也缺,这是当前口径,由相隔 23 天、互相独立的 2 次普查得出且落在同一个数:2026-07-30 14 词 654 条 → 17/654 = 2.6%(即有案号 97.4%)、2026-08-22 14 词 643 条 → 17/643 = 2.6%(即有案号 97.4%)。站内另有一个更早、更小的读数 4.9%,它不是第二个「当前口径」:2026-07-30 6 词 224 条 → 11/224 = 4.9%,未按关键词分层、样本量只有当前那几次里最小一次的 35%(224 条 vs 643 条)。它被同日那次分层复测当场取代,照登在这里是为了不抹掉自己的测量史(站内复测命令段里仍写着它),但凡是拿它当现值的地方都是过期读数。另一条线不要混着算:省份/案由浏览线 2026-07-30 80 条 → 0/80 未见缺失,它与关键词检索线是两条不同的取数线(同一套语料、两种抽法),两边的比例既不能相加也不能互相换算。别把「4.9% → 2.6%」读成上游把案号补上了 —— 恰恰相反,相隔 23 天的两次普查读到同一个数,说明这段时间没有变化;差别只在于第一次样本小、又没按关键词分层,是抽样上的高估,不是数据变好了。也别把 2.6% 读成「哪个词都是 2.6%」 —— 缺口高度集中在婚姻家庭/人身类查询,按检索词看差距很大(那组按词拆开的读数不在本段,单一来源在结果列表的「无案号」口径里,本段刻意不再抄一份),拿这个全站均值去估自己那类检索会严重低估。再补一句:站内这个数被拿去和别处的读数相减过,而那种减法做不得。第 660 发同日另有一份 2,675 条的样本(非空 2,620 条),折算下来缺案号比这里低约半个点;但那份样本用的不是同一份词表(它的逐条举证里有 `q=工资`,而本口径这 14 个词里没有它),而且它只记了词数、没记是哪几个词 —— ⇒ 两份样本事后连同词子集都抽不出来,谁高谁低都不构成「这个数变了」。那到底变没变?本站另做了一次可比的测量:词表逐字不变、同一条线、同一个 pageSize,2026-08-27 重打。同词同页深那一层读到 17/643 = 2.6%,与 2026-08-22 那次不只是合计相同,14 个词的格子逐个相同;另取 7 个承载页原样复打,逐位相同。⇒ 时间上这个数一点没动(0.000 个点)。反过来也别把它读成「两次独立普查互相印证」 —— 同形状的重打是确定性的,它证明的是「这个数没动」,不是「这个数被独立复现了」。那半个点的来路是「翻多深」,不是「哪一天」。同一批词、同一时刻,第 1 页 2.644%、第 2-4 页 1.938%(-0.705 个点),四页合起来 2.109% —— 方向与量级都盖得住那半个点。这个差在本样本量上与噪声分不开,但不管它是页深还是噪声,都不是「上游把案号补上了」 —— 时间那一项已经实测为 0.000 个点。所以本站刻意不给这个数印一条「±X 个点」的误差棒。按样本量算出来的那条约 ±0.63 个点,量的是「同一份词表再抽一次会晃多少」,而这个数真正的晃动来自换词:本轮 14 个词里有 9 个在各自约 120 条以上的深度里一条都不缺,而单独一个词(`离婚`)就扛走了缺口的 51.8%。换掉名单里一个词,就能把这个「全站均值」推得比那条误差棒更远,而且是确定性地推。⇒ 请把它读成「拿这几个词去问时的条件均值」,不是「全库的缺案号率」;要估自己那类检索,唯一靠谱的办法是拿自己的词去打一遍。再补一条读法:本站很多读数后面跟着「复打 N 轮逐位相同」,那句话说的是「这个数没动」,不是「这个数被独立复现了」。同一个形状(同一份词表、同样翻到第几页、同一个 `pageSize`、同一条线)重打是确定性的 —— 再打十轮也还是那一份数据读十遍,不构成第二份证据。2026-08-27 本站把「形状」的三个维度逐个换掉各打一枪(每种形状复打 2 轮,`doc_id` 序列逐位相同),结论如下。① 换 `pageSize` 不产生新样本,只产生嵌套子集。同 14 个词,把 `pageSize` 从 50 改成 40,14/14 个词的 `doc_id` 序列是前者的逐位前缀 —— 换的不是取哪些行,是截到第几行。但读数会跟着动:同一批词、同一时刻,`pageSize=50` 读到 2.644%(17/643),`pageSize=40` 读到 2.924%(15/513),差 +0.280 个点。⇒ 引用本站任何抽样比例时必须连 `pageSize` 一起引,但别把换 `pageSize` 当成第二份样本。② 换端点也不产生第二条线 —— 这一条对拿本站做交叉核对的人最要紧。`/api/cases/search` 与 `/api/cases/search2` 看起来是两个检索端点,实测同 14 个词、同 `pageSize=50`,14/14 个词的 `doc_id` 序列逐位全等,合计读数同为 17/643。⇒ 拿这两个端点互相印证,是同一条线读两遍;要真做交叉核对,请直接去中国裁判文书网按案号核对原文(站外证据);站内另一套语料只有 `/api/v1/search`(Turso 样本库,覆盖远小于全量)。(两个端点认的参数集并不相同,本段只说「拿它们互证无效」,不是说其中一个多余。)③ 真正算得上对照的,是换掉词表里的词 —— 本站那两次相隔 23 天的普查正是这一种,而且现在对平了。2026-07-30 那次 654 条与 2026-08-22 那次 643 条差 11 条,长期只知道「不是逐字重打」;本轮把两份词表作差(各 3 个词不同)并把这 6 个词今天亲打一遍:共有词 510 条,加上前者独有的 144 条正好是 654 条,分子两边同为 17 条。⇒ 那 11 条全部由词表差解释,不含任何时间漂移;两次落在同一个数,证明的是对换词的稳健。但这份稳健只到这里为止:换进换出的那 6 个词今天实测缺案号都是 0,替换发生在已经为 0 的那一侧;而本站另一段量过,单独一个高缺口词就能扛走一半以上的缺口。请读成「零缺口词之间互换时稳」,不是「换哪个词都稳」。再补一条读法:本站多处写过「N 条互相独立的上游」,而按代码里实际读的那个 base 归并,14 个对外端点(另有 1 个内部路由)身上 18 处取数点,只落在 3 个 base 上。其中 `/wscx` 与 `/wscx2` 是两个 ES 服务(2026-08-27 各自 `/health` 自陈 `es-search ver 103` / `es-search2 ver 216`),对外能拿去交叉复核的另一套语料只有 `/api/v1/search`(Turso 样本库) ——注意这句「只有」说的是唯一可复核的对外检索线,不是「唯一读 Turso 的端点」(Turso 上还挂着详情回退、计量与一个内部路由,它们都不是复核入口)。最要紧的一条:全量库浏览线(`/api/cases/browse`、`/api/v1/judgements`)自 2026-07-23 后端切到 ES 起,读的就是 `/wscx2` —— 与检索 `/api/cases/search2` 同一个 base,而本站此前多处仍把它写成「另一条上游(.237 全量库 `:3000`)」并推荐拿它交叉复核。还有一条比「端点多而 base 少」更麻烦的:3 个端点自己就横跨两个 base(`/api/cases/search2`、`/api/v1/health`、`/api/v1/cases/[id]`),问它「你读的是哪条线」本来就没有单一答案;其中 `/api/cases/search2` 更会在主线失败时静默退到另一个 base ——所以「拿 `/api/cases/search` 与 `/api/cases/search2` 互相印证」这件事,在降级那一刻读的是同一个 base,那次对账是同义反复。① 两个 ES base 在「都认识」的条件上返回的是同样的行。2026-08-27 直打两个上游(绕开路由与配额墙),`q=貔貅`、`pageSize=3`:两边都认识的 5 格(基线、`yearFrom`、`yearTo`、`province`、以及一个双方都无视的乱键)`total` 与 `doc_id` 序列全部逐位全等;另 3 格(`sort` / `docType` / `lastYears`)确实分家,但那是因为 `/wscx` 根本不认识这几个键、返回的是「没有这个条件」的答案(`4,392` 对 `4,355`/`3,726`/`535`)。⇒ 分家由「一条线把键丢了」完整解释,不是两份数据。换成 14 个高频词、`pageSize=50` 再打一遍:13/14 个词的 `doc_id` 序列逐位全等。② 因此「换一条上游交叉复核」这句指路,此前指错了地方。2026-08-27 当场取证:同一个 `province=浙江省`,浏览线返 7,512,973、直打 `/wscx2` 返 7,512,973,前三条 `doc_id` 逐位相同;连 `/wscx` 都返回同样那三条(只是 `total` 被封顶成 10,000)。⇒ 要真做交叉核对,请用 `/api/v1/search`(另一套语料,但它是样本库、覆盖远小于全量),或直接去中国裁判文书网按案号核对原文 —— 后者才是本站之外的证据。两条必须一并知道的射程:㈠ `total` 那一位两条 ES 线永远不等且与数据无关 ——同 14 个词里 `/wscx` 14/14 全部返封顶值 10,000、`/wscx2` 返真值(933,083 … 46,907,615),所以跨线对账在 `total` 位必然报警、在 `doc_id` 位必然全等,两位读出来的结论相反;㈡ 那 14 个词里有 1 个(`q=工伤`)当场撞上单侧静默零 ——`/wscx2` 返 HTTP 200 + `total:0` + 空 `cases`,同一分钟另一条返满页,复打 12 轮 0/12 复现。一次单侧静默零长得就像「两条线数据不一致」,而它其实是一条线当场坏了 —— 这是跨线对账本身的陷阱,别把它读成数据打架。再补一条射程:上一段那句「两个 ES 线返回同样的行」只说 `/search`,而这不是「别的没量」——是别的没有可比对象。2026-08-27 直打两个上游各复打 2 轮(逐格相同):`/wscx` 出数据的是 `/search` 与 `/agg`,`/wscx2` 出数据的是 `/search` 与 `/related`,两条线共有的只有 `/search` —— `/agg`、`/doc`、`/related` 各只在一条线上存在(其中 `/doc` 在 `/wscx2` 上存在但只认 POST)。⇒ 「换一条 ES 线核对」这件事,能做的只有检索本身;聚合、详情、相关案由三处,换过去得到的不是「另一份答案」,是「没有这条路由」。而两条线报「没有这条路由」的方式不一样,这一位很要紧:`/wscx` 返 HTTP 404;`/wscx2` 返 HTTP 200 + `{"error":"no route","total":0,"cases":[]}` ——一份形状完全合法的空结果。同日实测一次真的零命中(`q=貔貅&yearFrom=2030`、`q=zqxjkwmvbn7788`,两条线各打)返回的键恰好是 `cases`/`page`/`pageSize`/`total` 四个、没有 `error`。⇒ 在 `/wscx2` 上,`error` 键是把「上游没这条路由/方法不对」与「真的零命中」分开的唯一一位,HTTP 状态码那一位分不出来。本站对这一位原本有两套判法,其中一套读不出 —— 2026-08-27 已把当时点到的 3 处全部补上。把那份信封原样喂进各判定入口(行为实测,不是读代码):现在 8 个入口全部先看 `error` 键、一律判失败,读不出的已经是 0 处。其中 2 处是补在前一发的(`lib/es-clean.ts checkUpstreamSearch`、`lib/full-corpus.ts 取数层`),补之前它们把这份信封读成一次合法的零命中、连错误文字都丢掉,受影响的对外端点是 `/api/cases/browse`、`/api/cases/search`、`/api/v1/fulltext`、`/api/v1/health(全量库探针)`、`/api/v1/health(检索探针)`、`/api/v1/judgements`;补之后这几个端点在这一支改返「失败 + 上游原话」,不再是一份看起来正常的空结果。凭什么敢收紧 —— 收紧的风险是把「真的没有」错判成故障,比不收更坏,故先量了一轮:2026-08-27 直打两条上游,把能驱动到零命中的 8 个形状各打一枪(省份不存在、年份区间在库外、年份区间写反、深翻页、关键词 + 省份组合、四维叠加),8 枪全部没有 `error` 键,返回的键恰好是 `cases`/`page`/`pageSize`/`total` 那几个。⇒ 这一位只在上游报错时出现,收紧不误伤真零命中。射程要连这条一起读:`docType`、`caseType`、`court` 这几维驱动不出零命中 —— 同日实测填一个不存在的值,上游不是归零而是把这一维整个忽略掉、返回更大的数,故它们不在上面那几枪里(这也意味着:这几维写错时你不会看见 0,只会悄悄拿到一份没被筛过的结果)。最后那 1 处是怎么收的 —— 顺带把本站自己写错的一句订正掉。前一发把 `app/api/cases/related/route.ts` 记成「读不出」并登记为下一项;2026-08-27 真把那份信封喂进去(行为实测)才发现:修前它返的是失败,挡住了 ——但不是因为读得出那一位,而是键名撞不上:信封装的是 `cases`,而 `/api/cases/related` 读的是 `causes`,于是被那道形状闸顺手挡下。这是巧合,不是判据,而且没有任何闸把这个巧合按住 ——把同一份信封改成带 `causes: []`,修前立刻返一份 `ok:true` 的空结果,与一次真零命中逐字节同形。⇒ 那句「读不出」的结论方向是对的、给的理由是错的,两者都已照实改掉:这一处现在先读 `error` 那一位、并把上游原话带出来。同一枪顺带量到第二个盲点(此前一处都没记过):`/api/cases/related` 修前整位不读上游自陈的 `ok` ——`{"ok":false,"error":"…","causes":[]}` 会被读成一次正常的零命中。这一位也一并补上了。射程要连这条一起读:上面那 2 个形状是假想的 —— 2026-08-27 直打 `/wscx2/related` 试了 8 枪(正常 / 真零命中 / 空 q / 不带 q / ES 语法字符 / 超长 q / 路由写错 / 换请求方法),一枪都没能驱出「同时带 `error` 与 `causes`」的信封 ⇒ 就今天的上游而言那个洞够不着,修它的理由是「把巧合换成判据、把上游原话带出来」,不是「线上正在出错」——这两句话不许混讲。顺带订正一条射程:上一段那张「两条线两种报法」的表够不着第三种 ——`/wscx2/related` 遇到请求方法不对返的是 HTTP 501 + 一张 HTML 错误页(连 JSON 都不是),既不是 200 信封也不是 4xx JSON。2026-09-01 又补上第 8 个入口 —— 它不是「补得晚」,是这张普查表从来没把它列进来过。上面那轮把当时点到的入口逐个收了口,但 `app/api/analytics/route.ts fetchAgg` 一次都没被登记过 —— 因为 2026-08-27 量的时候 `/wscx` 的 `/agg` 正常出数据,没人想到去喂它一份错误信封。这一位是纪元相关的:2026-09-01 那天检索引擎拒连,同一条 `/wscx` 上的 `/search` 与 `/agg` 两个 handler 都改发了 `error` 键,发的是同一句上游原话 `<urlopen error [Errno 61] Connection refused>`(各复打 3 轮,逐字节相同)。⇒ 那一格 `hasErrorKey:false` 记的是健康纪元、并不等于「这个 handler 从不发这一位」,两个纪元并存,不许拿其中一个去否证另一个。修前它挡得住吗 —— 挡得住,但和上一段那处同病:靠的是巧合。信封里没有 `items` 键,被那道形状闸顺手挡下,所以它照旧返失败;可巧合挡得住「要不要报失败」,挡不住「失败的理由是什么」。丢掉理由的代价这次是实打实的:上游把根因写在回话里,而本站对外把它讲成「报文结构不合约定 / 需要后端修复 / 重试通常不会改变结果」——成因、责任人、该不该重试,三句都反了(真实成因是它依赖的下层这一刻取不到数,恢复后同一个请求即可出数)。受影响的对外端点是 `/api/analytics`、`/sifa 专题页(取数)`、`MCP case_analytics`,而这几个恰是全站唯一出数字的一路。现在这一支改判成 `upstream_reported` 并把上游原话带进 `_diag`,`bad_shape` 收窄成「既没有 items、上游也什么都没说」那一族(分支单一来源 lib/analytics-agg-fail-branches.ts)。2026-09-01 再补第 8 个入口 —— 而这一个的意义跟上面七个都不一样:它本身是好的。`app/api/ai/qa/route.ts fetchRagCases` 服务的 `/api/ai/qa` 修前就先看 `error` 那一位、一律判失败,而且靠的是判据、不是上面两处那种「键名撞不上」的巧合;它对用户说的那句「本次类案检索这一步失败了(检索服务未正常返回)——这不代表库里没有相关判决」,成因、责任人、该不该重试三句都没说反。所以登记它的理由不是它坏,是它证明了本站那道自称管这件事的闸看不见它。那道闸(反向全目录扫描)的头注写着「有没有漏行由它负责,不再靠人自觉」,而实测它有两个结构性盲区,任一个单独就够漏:㈠只扫 route 文件,而这处的 URL 字面量在 `lib/` 里、由 route 经 helper 调进去;㈡按手写的常量名单认 base,那份名单只有 5 条 —— 另一个同形状的取数点 `lib/full-corpus.ts` 之所以在表里,正是因为当初有人手工把它那条模式补进了名单,即那道闸只是把「靠人自觉」从维护端点表挪到了维护模式表,并没有消掉它。本发换了判据:不认名字,改成从源码现算的两条合取 —— 文件里有可 fetch 的 `/wscx``/wscx2` 绝对 URL 字面量,且同一文件里有 `fetch(`。实测把 19 个命中文件干净分成 11 个取数点 + 8 个文案点(后者逐个验过不含 `await fetch(`)。这段话的射程:今天漏的这一个恰好是好的,下一个漏的不一定 —— 本发换掉的是「靠谁记得」这条机理,不是修好了某个正在出错的端点;这两句不许混讲。最要紧的一条边界:这一改治不了「静默零」。它只治「上游明说自己错了、而我们把这句话丢掉」那一支;`total:0 + cases:[] + 没有 error` 那一族(本站此前反复记录的那个形状)逐字节不变,各线的 `zero_result_kind` 仍旧是 `indistinguishable`。另两条边界照旧:㈠ 本站没有证明此前观测到的那些静默零就是错误信封 —— 只证明了若是,修前会被读成零命中且事后无从分辨,修后才读得出来;两件事不许混讲。㈡ 量这一切的那天两条线都活着(`/health` 自陈两个不同版本),讲的是错误的报法,不是某条线坏了。给读者的自助判据:一次 200 的空结果若来自这几个端点,请换一个必然有命中的条件复打一枪 —— 同一条件下别的查询照常出数据,才说明那个 0 是「真的没有」。/api/cases/related 的降级响应此前分不出「为什么降级」。它有 5 条失败路径(!res.ok / JSON.parse 抛错 / !Array.isArray(causes) / catch + AbortError / catch + 非 AbortError),修前全部返同一份逐字节相同的空结果,调用方拿到的只有一个 ok:false,连「是上游报错了还是我们没连上」都分不出来。2026-08-27 起每一支都带上自己的 code 与一句人读诊断。其中 1 支今天就够得着,而且线上真的在返它 —— !res.ok:q = 11,000 个半角逗号(路由把每个逗号 encodeURIComponent 成 %2C,3 倍放大 → 送出的 q 编码后 33,000B,连同 base/path 前缀越过上游 nginx 请求行上限 32,768B);上游 HTTP 414 + text/html(nginx 通用错误页)。分界线极窄:q = q = 10,900 逗号时本端点返 ok:true、= q = 11,000 逗号时返 ok:false,两份响应修前只差 ok 一位。复核这一支必须走 HTTP/1.1 —— curl 默认 HTTP/2 会把那条巨长的请求行 HPACK 压掉,同一条 URL 照返 200;而本站的 fetch(Node undici)走 HTTP/1.1,原样发出去,上游返 414。不加 --http1.1 会得出「上游没事」的反结论。射程(不写这条本段会被读得比实测更宽):另外 4 支今天够不着 ——JSON.parse 抛错(今天能驱出的非 JSON 页面(414、换方法的 501)全部带非 2xx,一律先落进 !res.ok 那一支)、!Array.isArray(causes)(/wscx2/related 在 200 上一律返 causes 数组;唯一不带 causes 的 JSON 是错误信封,而它带 error、已被第 666 发那道闸先接走)、catch + AbortError(上游实测 0.33s,超时给的是 15s,量级差 45 倍)、catch + 非 AbortError(直打上游要到 60,000B / 80,000B 才在传输层断,而本站边缘在 q≈16,600 逗号(编码后 q 49,800B)就先返 431 —— 断点在本站边缘之外)。⇒ 修它们的理由是「把四支说清、把超时与连不上分开」,不是「线上这四支都在出错」。刻意没做的两件事:㈠ 非 2xx 那一支不读上游 body —— 今天那是 nginx 的通用 HTML 错误页,没有一句值得引的上游原话,只带状态码与 content-type(两样都在响应头上);㈡ 抛错那一支只带异常名,不带 message/cause —— 那两样会把内部 base URL 漏进公网响应。另外,本发与上一发是两件事:上一发治的是「上游明说自己错了」,本发这 5 支是「我们自己判它失败」,故 code 一个都不复用。前端行为逐像素不变:降级铁律没被这一改破掉 —— 列表页只读 causes 与 _meta,四支照旧 causes: [] + HTTP 200 + 不发缓存头(第 527 发那条口径)。新增的 code/error 只给机器侧读者看。第 668 发起,非 2xx 那一支还会报「我们把什么送了出去」 —— q 的字符数(码点) / q 编码后的字节数 / 编码放大倍数,让调用方当场看得出 q 进来时是一个长度、送到上游时是另一个(本端点 encodeURIComponent 会放大它)。但披露长度不等于指认成因:!res.ok 捕的是任何非 2xx,上游/网关 5xx(502 / 503 / 504)落进的是同一道闸,而那一刻 q 可能只有 6 个字节、与失败毫无关系,故只有 HTTP 414 才写成成因,其余状态码一律标注「供对账、不指认成因」。本发直打上游逐形状 9 枪(全程 --http1.1;方法那三枪各打 2 发,读数一致)证实:经本端点、由调用方驱得动的非 2xx 今天只有「q 太长」一种(路由写错 / 不带 q / ES 语法字符 / 控制字符 / 超大请求头 / 未越线的长 q 全部 200),而换 HTTP 方法能驱出 501 —— 那一种本路由够不着(方法写死 GET),但它证明这道闸本身不是长度专用闸。同时订正上一发自己漏出去的一位:上一发的正文里写过「上游 URL 共多少字节」,而驱动它的 q 长度与路径写法同段就在 —— 一次减法就能反推出内部 base 地址的精确长度,且这句话当时随本段渲染在 4 处公网出话口上。现已只报 q 那一半:上游 URL 总字节数 / 剩余可用额度(= 上限 − 前缀) / base/path 前缀本身的长度一律不发(上游 URL 总长 − q 编码后长度 − 路径长度 = base 长度;而路径与 q 长度本发都要公开(否则复核不了),故总长这一位必须扣住),运行期那行披露同理。刻意没做的第三件事:没有给 q 加自动截断 —— 截断会让调用方以为搜的是 A、实际搜的是 A 的前缀,那是改检索口径,不是披露。第 669 发起,这一位改成在成功那一路上恒发,因为本发量到它此前只有三类调用方里的一类拿得到。 encodeURIComponent 的放大倍数按 q 的字符类分三档(未保留 ASCII ×1 / 保留 ASCII(, / ? : @ & = + 等) ×3 / CJK / 非 ASCII ×9),而入站与出站各按自己的倍数长 ⇒ 先撞哪堵墙按字符类翻面。两堵墙:上游那道 414(路由跑了、看得见、报得出,sent 就挂在那儿)与我们自己的入站边 431(本站 Node 层(请求头上限),在路由之前,没有 body —— 没有 ok、没有 code、没有 error,四支诊断一个字都送不出去)。实测:只有保留 ASCII(, / ? : @ & = + 等)够得到上游那道(q = 10,900 字返 ok:true、q = 11,000 字返 ok:false —— 入站边(q ≈ 16,000 字)尚未满,出站已顶穿上游墙);未保留 ASCII(q = 16,000 字仍 200(入站边尚未满);上游墙要到 q ≈ 32,700 字,走不到)、CJK / 非 ASCII(q = 1,750 字仍 200、q = 1,800 字返 431(无 body);上游墙要到 q ≈ 3,600 字,走不到)先撞我们自己那道哑墙。⇒ 第 668 发那位 sent 只有保留 ASCII(, / ? : @ & = + 等)拿得到,而本产品的真实调用方全是中文关键词,恰恰是拿不到的那一类。故把它挪到他们唯一还拿得到 body 的地方:成功响应,且恒发 —— 条件发 = 发这件事本身即阈值;而阈值 − 已公开的 q 长度 = 前缀长度,所以 入站/出站的上限值 / 剩余可用额度 / 上游 URL 总字节数 / 距离上限还有多远一个都不带,内容仍只有 q 的字符数(码点) / q 编码后的字节数 / 编码放大倍数。没做的三件:㈠ 那 5 支失败路径一位没动(sent 仍只挂 !res.ok 一支);㈡ 入站边那堵墙在本站 Node 层、在路由之前,属后端基建,本发只量不碰;㈢ 仍旧没给 q 加截断。按词拆开:q=离婚 18.0%(9/50)、利息 8.1%、工伤 6.0%、抚养 4.1%, 而民间借贷/劳动争议/交通事故/买卖合同/继承/房屋买卖等 10 词均为 0%。 这类条目退不回「案名 + 法院 + 裁判日期」核对:同批 17 条里法院字段无一是真法院名 (0/17,写的是裁判文书网的不上网/不公开事由)、裁判日期仅 3/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 当作核对通过。把「未验证」读成「已证伪」是另一种假话。⚠️ 回核用的「案号 + 法院 + 裁判日期」这三样,并不是每条结果都给得出:2026-08-22 现网实打本站免 key 检索线(`/api/cases/search`,14 词 × `pageSize=50` 共 643 条,复打 2 轮读数逐位相同),三样齐全的只有 546/643 = 84.9%(在有案号的那 626 条里也只有 87.2%);分开看:有案号 97.4%、其中带真实法院名 97.1%、带裁判日期只有 90.1%。而且缺口不是均匀撒的 —— `民间借贷`/`交通事故`/`房屋买卖`/`建设工程`/`侵权` 这些词三样齐全率是 100%,而 `抚养` 38.8%、`利息` 45.9%、`离婚` 52.0% ⇒ 拿常见商事案由抽样自测必然全绿,真踩到的是婚姻家庭/人身类查询的读者。两个锚点还塌在不同的词上,所以「挑一个词试试」也验不出来:在有案号批内,掉法院的是 `利息`(真实法院名 18/34 = 52.9%),掉裁判日期的是 `抚养`(19/47 = 40.4%),两者互不重叠。另需分清:有案号有日期、单单法院是空串的有 18 条,与另一类 court 脏值不是一回事——后者指的是 court 字段里存的不是审理法院名、而是裁判文书网的不上网事由原文(2026-08-22 同一轮普查里只出现 2 种取值:「人民法院认为不宜在互联网公布的其他情形」「离婚诉讼或者涉及未成年子女抚养、监护的」),这类 14 条,无一条有案号——它们正是本轮 643 条里缺案号那 17 条中的 14 条,所以「按案号回核」这条路对它们本来就不成立,而上面那 18 条是有案号的,只是没写法院名。本段讲的是 court 字段;若在别处读到「正文只剩一句依法不上网的理由」那类说法,那是 body_text 字段上的另一组读数,别与这 14 条相加或互相换算。那批的口径盖不住这里。上面那条「别读成走不通」在这里同样成立 —— 案号本身就足以在该站检索,法院与裁判日期是用来消歧的加分项,不是缺了就核不成;案号仍是本站能给的最好回核锚点(原文直链是真空的),这条推荐不变。本段只钉住一件事:别把「记下这三样」当成总是做得到 —— 约每 7 条就有 1 条做不到,碰上只剩案号的条目,直接拿案号去检索即可,不必以为是自己漏看了字段。⚠️ 再往下一层:上面那个「有案号 97.4%」量的是 `case_no` 非空,不是「这个案号拿得去检索」。本轮普查里 court 一侧是验过形态的(靠 `court_is_court_name`,上面那 14 条正是这么揪出来的),而 case_no 一侧只验了非空 —— 而回核推荐押的恰恰是 case_no。2026-08-22 同一份样本逐条验案号形态(「(年份)+法院代字+类型+序号+号」),有案号那 626 条里形态不完好的有 2 条(0.3%),坏法还不一样:`4475`(q=`民间借贷`,裸序号——没有年份、没有法院代字、没有案件类型,补不回来,拿它检索不出任何东西)、`(2022)苏0322执恢92`(q=`民间借贷`,末尾缺一个「号」字,形态被截断,人工补一个字还能用)。这只是形态一关:形态完好不等于到裁判文书网真搜得到(那条边界另有一段,说的是「这条路我们没验过、也没法用状态码验」,别把两者混成一件事);本段只钉住:连形态都不完整的那 2 条,不必等到去搜才发现。同样别把这段读成「案号不可信」 —— 624/626 = 99.7% 形态完好,推荐不变;真正一点办法都没有的是 1 条。本段只钉住一件事:「有案号」这个勾,不等于「这个案号能用」 —— 按 97.4% 去估「能回核的比例」会略微高估,真正形态完好的是 624/643 = 97.0%。⚠️ 再往下还有一层,而且方向不一样:案号是给站外核对用的引用锚点,不是本站的检索键。上一段说的是案号长得完不完整;这一段说的是把一个长得完全没问题的案号打回本站检索框,会发生什么。2026-08-22 从同一份样本里取 20 条形态完好的案号,逐条原样当关键词打回 `/api/cases/search`(每次看首页 20 条),取回自己那份文书的有 0 条(复打 2 轮,20/20 逐位相同)。更要紧的是失败长什么样:20 次查询共返回 393 行,其中 68 行与目标同一家法院、却不是目标那一份(最坏一格 `（2018）鄂0683民初3148号` 是 18/20),另 325 行连法院都不是同一家。即它不会告诉你「没找到」,它会给你满满一页看起来像找对了地方的别的案子。一条线索(只是线索,别当定论):另一条线的 `q_tokens` 显示,案号被切开后序号那一段整个不在里面 —— `(2018)豫0621民初2797号` 切成 「民初」「0621」「豫」「2018」,没有「2797」;`(2022)苏0322执恢92号` 切成 「执」「恢」「2022」「苏」「0322」,没有「92」。序号恰恰是同一法院同一年同一类案件之间唯一的区分位。但这只有 2 个案号的实测,样本太小,不足以当机理下结论,此处只作线索登记。别把这段读成「按案号回核走不通」 —— 回核推荐指向的是中国裁判文书网,案号在那边是有效的定位符,那条推荐一个字不变;本段只把方向说清楚:拿到案号请往站外去核,别指望在本站搜索框里把它搜回来。也别与上面两段混:一段讲「案号长得完不完整」,一段讲「站外那条路没验过」,本段讲「站内这条路取不回自己」,三件事各说各的。⚠️ 上面那句「取不回自己」量的是首页 —— 而往下翻页也救不回来。 上一段每个案号只看了首页 20 条,于是留着半个问题:搜不到的人顺手往下翻几页,会不会在更深的页码上撞见目标?若会,那句话就该收窄成「首页取不回」。2026-08-22 本发把它打完了:不必收窄。同一条免 key 线、同样 20 条形态完好的案号,这次每条连翻 10 页(pageSize=50),共扫过 不少于 9,703 行,其中 615 行仍是同一家法院的别的案子 —— 取回自己那份的依旧是 0 条。复打 2 轮,「命中 0 条 / 触顶 20 条 / 同法院 615 行」三项逐位相同(扫过的行数两轮有几十行漂移,是上游逐页去重所致,故此处按较小的一轮讲)。再挑一条把整个可翻页窗口翻到底:`（2018）鄂0683民初3148号` 连翻 200 页(= pageSize 50 下的翻页上限),两轮分别取回 9,956 行 与 9,807 行,目标仍不在里面(最少的一轮也扫了 9,807 行)。⇒ 这不是「排得靠后」,是「翻多少页都不在」。还有一层别读反:这 20 次查询每一次的 `total_is_capped` 都是 true(total 恰好等于窗口容量),所以上一句的「翻到底」也只是翻完了相关度最高的那一薄片,并不等于翻完了该词的全部命中。窗口本身是什么、它截掉了什么,不在本段 —— 那是响应里 `window_note` 与排序窗口那一条单一来源的事,请去读那一条,别把两段读成一段;本段只借它说明一件事:连「翻到底」都不是「看全了」 —— 所以「多翻几页总能找回来」这个念头从一开始就没有落脚点。别把这段读成「按案号回核走不通」 —— 回核推荐指向的是中国裁判文书网,案号在那边是有效的定位符,那条推荐一个字不变;本段只是把上一段的射程量实:站内搜不回来,不分首页还是第 10 页。也别与前面几段混:一段讲「案号长得完不完整」,一段讲「站外那条路没验过」,一段讲「站内首页取不回自己」,本段讲「往下翻页也取不回」,四件事各说各的。⚠️ 上两段都是把案号整串塞进关键词框 —— 那「拆开送」呢? 读者手上的案号本身就含年份与法院代字,而本站检索另认 `yearFrom`/`yearTo` 与 `court` 两个键;所以上一段那句「站内取不回自己」还欠半个答复:会不会只是送法不对?2026-08-23 本发把 6 种送法一次打完 —— 不是送法不对。同一条免 key 线、同样 20 条形态完好的案号,每种送法各打首页(pageSize=50),复打 2 轮、6 种送法的命中数逐位相同:案号整串当关键词(上两段那种送法) 0/20;拆开送:序号当关键词 + 年份区间 4/20;序号 + 年份 + 法院名(连法院名都替读者查好) 3/19;案号整串 + 年份 + 法院名 0/19;只送序号,不加年份 2/20;序号 + 法院名,不加年份 3/19。(其中 3 种送法的分母是 19 而不是 20,因为样本里有 1 条连法院名都是空串,这几种送法对它根本做不出来。)⇒ 「拆开送」不是全无效,但最好的一种也只有 4/20;四种拆开送法全试一遍,命中并集也只有 7/20。而且把法院名一并送进去并不加分(4 → 3) —— `court=` 是分词 OR 匹配、不是精确过滤器,这一点归 `window_note` 那条单一来源,本段只报读数、不在这里展开。真正咬住的是年份键:它筛的是「judgement_date(裁判日期)」,不是案号里那个年份。 对照臂(对照:拿这条文书当初出现的那个检索词 + 同一个年份区间)命中 14/20,说明结构化键本身没坏;而没命中的那 6 条,正是「裁判日期为空、或裁判日期的年份与案号里的年份对不上」的那 6 条,一条不多一条不少(其中 3 条裁判日期整个为空 —— 任何年份区间都筛不到它;另 3 条差着年,例如 `(2014)黔执99999号` 的裁判日期是 2018-07-13(差 4 年))。⇒ 读者从案号里读出年份、当成筛选年份送进去,恰恰把目标自己筛掉了。所以本段给不出「正确的搜法」,这不是偷懒:加年份能救回的那批与不加年份能救回的那批,命中集合完全不相交 —— 要选对送法,得先知道这份文书的裁判日期对不对得上案号里的年份,而裁判日期正是他还没拿到的那份文书里的字段。这个圈自己咬着自己。(⚠️ 第 641 发就地收窄:上面这 6 种送法里一种都没送 `province`,而它是这几个键里唯一真把结果集缩下来的那个 —— 加上它之后最好的一种能到 6/17。所以「给不出正确的搜法」这句,只对不含 `province` 的那几种送法成立;加了 province 之后是什么样、以及从案号读省份自己有哪些坏法,全在下一段,本段不展开。)别把这段读成「按案号回核走不通」 —— 回核推荐指向的是中国裁判文书网,案号在那边是有效的定位符,那条推荐一个字不变;本段只是把上两段的射程再补一刀:站内取不回来,不分整串还是拆开送。也别与前面几段混:一段讲「案号长得完不完整」,一段讲「站外那条路没验过」,一段讲「站内首页取不回自己」,一段讲「往下翻页也取不回」,本段讲「拆成结构化键送也取不回」,五件事各说各的。⚠️ 上一段那几种送法里,一种都没送 `province` —— 而它恰是这几个键里唯一真会缩范围的那个。 2026-08-23 本发把它补打了:同一条免 key 线、同一份 20 条形态完好的案号,其中 17 条的案号代字读得出省份,七种送法全部在这同一批上重打(pageSize=50,复打 2 轮、命中数与触顶数逐位相同),故与上一段可直接比。逐臂读数(命中 / 触顶):案号整串 + 省份 0/17(触顶 17);只送序号 2/17(触顶 14);序号 + 年份 3/17(触顶 7);序号 + 法院名 3/16(触顶 13);序号 + 年份 + 法院名 2/16(触顶 6);序号 + 省份 3/17(触顶 5);序号 + 省份 + 年份 6/17(触顶 1)。对照臂(对照:拿这条文书当初出现的那个检索词 + 同一个省份)命中 14/17,province 键本身没坏。机理落在触顶那一列上:「案号整串 + 省份」17/17 格触顶,而「序号 + 省份 + 年份」只剩 1/17 格 —— province 是唯一把结果集真压到翻页窗口以下的键,目标于是不再被挤出去,命中也从「序号 + 年份」的 3/17 抬到 6/17。(把法院名送进去为什么不管用,归 `window_note` 那条单一来源 —— `court=` 是分词 OR 匹配、不是精确过滤器,本段只报读数、不在这里展开。)⇒ 上一段那句「给不出正确的搜法」得收窄:四种老送法的命中并集本发在同一批上复现出 7/20(与上一段逐位相同),加上两种带 province 的送法后升到 11/20。实测最好的送法是「序号 + 省份 + 年份」。但它离「正确的搜法」还差着三道,下面逐道说清 —— 别只把上面那半句抄走。㈠ 有相当一部分案号根本读不出省份。 624 条形态完好的案号里,103 条的代字不是省级简称。条数最多的几个是 「兵」30 条、「镇」6 条、「浦」6 条、「和」4 条、「杨」4 条(前 5 个合计 50 条,最大的一类是兵团;余下 53 条是老式县市代字的长尾)。另有一条本站自己的死条目:代字表里收的是通用简称「蒙」,而内蒙古自治区的法院在案号里写的是「内」——本样本里前者 0 条、后者 2 条,与第 445 发修掉的「贵 / 黔」是同一类。两头都已修:第 642 发补上了真正在用的那个代字;第 646 发把「蒙」这一格从案号代字表里摘掉 —— 本样本里 0 条只说明内蒙古自治区这一侧没人用它,定向普查一打就是 49 条,全部出自外省四家同名市县法院(广西蒙山 20 / 山东蒙阴 18 / 安徽蒙城 10 / 云南蒙自 1),其中云南蒙自那条现网已被读成内蒙古自治区。㈡ 读得出的那批,还可能读成错的省 —— 而且是静默的。 把 624 条按代字形态分开看:代字是「省简称 + 4 位数字」的新式案号 515 条,与库中省份对不上的只有 2 条,而这 2 条拿法院名当第三方裁决,错的是库里那一侧不是代字(`（2021）黑0726民初87号` 法院是南岔县人民法院,库里却写湖南省;`（2022）苏0191执2588号` 法院是江苏省江宁经济技术开发区人民法院,库里却写广东省)⇒ 新式代字读省份是可靠的;而老式案号 109 条里,有 37 条的首字恰好撞上省级简称,其中 5 条读错(`（2011）苏民初字第1694号` 的「苏」是郴州市苏仙区人民法院的字头,不是江苏省,实际在湖南省;`（2013）津行初字第44号` 的「津」是津市市人民法院的字头,不是天津市,实际在湖南省)。读错的后果不是报错,是返回整整一页那个省的别的案子 —— 与前面那段「同一家法院的别的案子」同族,读起来像找对了地方。㈢ 最阴的一条:卡片上印的省份,未必是能送进 `province=` 的那个值。 `(2025)黔0402执3359号` 的卡片上写着「贵州省」(它的 court 字段是空串)。不加省份查(序号 + 年份)总命中 571 条、没触顶,目标就在首页;只加一个 `province=贵州`,总命中变成 13 条、仍然没触顶(整份结果就在眼前),目标不在里面;换成全称 `province=贵州省` 同样 13 条、同样不在。既然两次都没触顶、结果集整份可见,这就不是窗口截掉的,是被 `province` 筛掉的 —— 上游那条记录的 province 字段是空的,卡片上那个「贵州省」是本站按案号代字回填的显示值。⇒ 读者照着卡片把省份送进去,恰恰把目标自己筛掉,与上一段「按案号读年份反而把自己筛掉」是同一种自噬,只换了一个字段。这一条本发只证到「确实存在」,没量它有多常见:回填是静默的,响应里读不出哪一条的 province 是库里本来就有、哪一条是补上去的。所以既别把它读成「省份键不可靠」(对照臂 14/17 摆在那儿),也别读成「只此一例」。别把这段读成「按案号回核走不通」 —— 回核推荐指向的是中国裁判文书网,案号在那边是有效的定位符,那条推荐一个字不变;本段只是把上一段的判词修正到位:站内取不回来这件事,加上省份之后从「几乎全军覆没」变成「小半能捞回来」,但仍不是一条可靠的路。也别与前面几段混:一段讲「案号长得完不完整」,一段讲「站外那条路没验过」,一段讲「站内首页取不回自己」,一段讲「往下翻页也取不回」,一段讲「拆成年份 + 法院名送也取不回」,本段讲「把省份也送进去能捞回一小半、以及从案号读省份自己的三道坎」,六件事各说各的。⚠️ 再补一种坏法:上面那两条举证说的都是「这是个案号,只是坏了」(裸序号 / 被截断),而还有一种是 `case_no` 里装着别的字段的内容 —— 那根本不是案号。2026-08-27 拿一份更大的样本复量:免 key 线 `/api/cases/search`,14 词 × 4 页 × 50 = 2,675 条(doc_id 去重后仍是 2,675 条,无重复行;是第 637 发那份的 4.2 倍),承载关键读数的 7 个页面原样复打逐位相同。先对个账:非空 2,620 条里不合形态 8 条 = 0.31%,与第 637 发的 2/626 = 0.32% 落在同一处(两份样本各自独立,别相加当全库口径)。再往下切一刀:案号必含序号数字,所以「非空且零阿拉伯数字」就不可能是案号 —— 这是条硬判据,与形态正则不是一回事(`4475`、`集民初字第766号`、`(2022)苏0322执恢92` 都不合形态,但那三条确实是案号,只是不完整)。按这条判据命中 3 条 = 0.115%,已逐条人眼复核:`执行裁定书`(q=`工资`,装的是文书类型)、`pt”>执行裁定书`(q=`工资`,同上,而且带着 HTML 残渣 `pt”>`(抓取时把标签尾巴一起吃了进来))、`原告：褚进运。`(q=`交通事故`,装的是当事人句)。射程:这条判据也会把假想中的全汉字数字案号(如「(二〇一四)…第一号」)误判成不是案号,本轮样本里一条都没有。但本段刻意不给「有案号」那个比例加限定句,两条理由都得摆出来:㈠ 0.115% 是长尾,而「缺案号率」这个数刚被统一成一个读数,为 3 条把它重新拆成两个,收益是负的;㈡ 更硬的一条 —— 这 3 条已经被站内现有的 court 判据全数接住:3/3 条的 `court_is_court_name` 为 `false`,而这面旗在全样本上的基准红率只有 3.29%(88/2,675)⇒ 共位不是碰巧,照现有口径读结果的人在这几条上本来就已经看到一面红旗。同样别把这段读成「案号不可信」 —— 2,612/2,620 = 99.7% 形态完好,推荐不变;本段只钉住一件事:「有案号」这个勾,最坏情况不是「拿到一个残缺的案号」,而是「拿到的根本不是案号」。最后划清一条界:另有一段讲的是 `province` 字段里装着法院名,本段讲的是 `case_no` 里装着文书类型 / 当事人句 —— 证据在不同字段、不同行上,别把两者合并成一句「上游字段普遍装错」,那等于把一边的可信度借给另一边。

能力边界与免责

文书查仅提供基于公开裁判文书的检索与统计素材,不预测裁判结果、不生成法律意见。 检索结果与统计数据供研究与代理工作参考,不得直接作为法律意见使用;具体案件请以律师与法院的专业判断为准。

与北大法宝的关系

文书查是对标北大法宝「司法案例」定位的独立法律数据平台,与北大法宝无隶属或合作关系,仅作产品定位参照。