fish2018/pansou · error

响应超过 字节

Error message

响应超过 %d 字节

What it means

Returned by doLimitedRequest when the response body exceeds the configured size limit (maxSearchResponseSize = 4MiB for search, maxDiscoveryBodySize = 8MiB for discovery). The LimitReader reads limit+1 bytes, so a body longer than the cap is detected and rejected to protect memory from runaway upstream responses.

Solutions

  1. Use a more specific keyword so the upstream returns a smaller result set
  2. If legitimate responses are being cut off, raise maxSearchResponseSize (trade-off: memory per in-flight request)
  3. If discovery triggers it, check what the homepage actually serves now — an unexpected page means the bundle/layout changed
  4. Keep the limit as a guardrail; prefer fixing the query over disabling the cap

Example fix

// before
maxSearchResponseSize = 4 << 20
// after: raise cap and log when exceeded
maxSearchResponseSize = 8 << 20
if int64(len(body)) > limit {
    return nil, fmt.Errorf("response exceeds %d bytes", limit)
}
Defensive patterns

Strategy: validation

Validate before calling

// use a specific keyword to keep upstream result sets small
if len(keyword) < 3 {
    return errors.New("keyword too broad; expected oversized response, refine the query")
}

Try / catch

if strings.Contains(err.Error(), "响应超过") || strings.Contains(err.Error(), "字节") {
    // oversized response: refine keyword or raise the size cap
    return refineQuery(keyword)
}

Prevention

When it happens

Trigger: The xiaokupan search response exceeds 4MiB (e.g. a very broad keyword returning an enormous result set), or the homepage/entry JS bundle fetched during function-ID discovery exceeds 8MiB (site switched to a much larger bundle or began serving an unexpected page, like a giant error/captcha page).

Common situations: Searching an extremely common keyword returns a huge merged result payload; the site's build pipeline outputs index JS >8MiB; the site starts serving a bloated interstitial page instead of the expected content.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors


AI-assisted analysis of fish2018/pansou@beaa561337 (2026-09-07). Data as JSON: /api/errors/ebda68ae143178cd. Report an issue: GitHub.

Appendix: source

Thrown at plugin/xiaokupan/xiaokupan.go:194

	req.Header.Set("x-tsr-serverFn", "true")
}

func doLimitedRequest(client *http.Client, req *http.Request, limit int64) ([]byte, error) {
	resp, err := client.Do(req)
	if err != nil {
		return nil, fmt.Errorf("请求失败: %w", err)
	}
	defer resp.Body.Close()
	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("HTTP %d", resp.StatusCode)
	}

	body, err := io.ReadAll(io.LimitReader(resp.Body, limit+1))
	if err != nil {
		return nil, fmt.Errorf("读取响应失败: %w", err)
	}
	if int64(len(body)) > limit {
		return nil, fmt.Errorf("响应超过 %d 字节", limit)
	}
	return body, nil
}

func (p *XiaokupanPlugin) currentServerFunctionID() string {
	p.serverFunctionMu.RLock()
	defer p.serverFunctionMu.RUnlock()
	return p.serverFunctionID
}

func (p *XiaokupanPlugin) refreshServerFunctionID(client *http.Client, staleID string) (string, error) {
	p.serverFunctionMu.Lock()
	defer p.serverFunctionMu.Unlock()
	if p.serverFunctionID != "" && p.serverFunctionID != staleID {
		return p.serverFunctionID, nil
	}

	discoveredID, err := p.discoverServerFunctionID(client)

View on GitHub (pinned to beaa561337)