Serde Code Review

开发编程

审查 serde 序列化代码，涵盖派生模式、枚举表示、自定义实现以及常见序列化错误。用于 Rust 代码审查。

630

下载量

安装量

收藏量

★ 5.0

综合评分ⓘ

概述

更多信息

Serde Code Review#

Check Cargo.toml — Note serde features ( derive, rc), format crates ( serde_json, toml, bincode, etc.), and Rust edition (2024 has breaking changes affecting serde code)
Check derive usage — Verify Serialize and Deserialize are derived appropriately
Check enum representations — Enum tagging affects wire format compatibility and readability
Check field attributes — Renaming, defaults, skipping affect API contracts
Check edition 2024 compatibility — Reserved gen keyword, RPIT lifetime capture changes, never_type_fallback
Verify round-trip correctness — Serialized data must deserialize back to the same value

Run in order. Do not write a finding until the step that applies has passed.

Serde context on disk — Pass when: You have read the relevant Cargo.toml (crate or workspace root) and can state Rust edition, serde / serde_derive features if non-default ( derive, rc), and which format crates apply ( serde_json, toml, bincode, etc.) for the code under review. Then apply edition-specific checklist items (e.g. gen, RPIT/ never_type_fallback) only when that file supports them.
Per-finding evidence — Pass when: Each issue cites [FILE:LINE] from the current tree for the struct/ enum, Serialize/ Deserialize impl, or attribute block in question (not from memory, docs-only, or another branch).
Category check vs protocol — Pass when: For the finding type (derive attrs, enum tagging, flatten, custom impl, sqlx + serde alignment), you ran the matching checks from the review-verification-protocol skill (e.g. full type definition + serde attrs before “wrong representation”; confirmed edition in Cargo.toml before edition-2024-only findings). Then add the finding.
Output shape — Pass when: The report lines match Output Format below (severity + description).

Report findings as:

text

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.

Issue TypeReferenceDerive patterns, attribute macros, field configurationreferences/derive-patterns.mdCustom Serialize/Deserialize, format-specific issuesreferences/custom-serialization.md

#[derive(Serialize, Deserialize)] on types that cross serialization boundaries
#[derive(Debug)] alongside serde derives (debugging serialization issues)
Feature-gated derives when serde is optional: #[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
Prefer #[expect(unused)] over #[allow(unused)] for serde-only fields (self-cleaning lint suppression, stable since 1.81)

Enum tagging is explicit (not relying on serde's default externally-tagged format when another is intended)
Tag names are stable and won't collide with field names
#[serde(rename_all = "...")] used consistently across the API

#[serde(skip_serializing_if = "Option::is_none")] for optional fields (clean JSON output)
#[serde(default)] for fields that should have fallback values during deserialization
#[serde(rename = "...")] when Rust field names differ from wire format
#[serde(flatten)] used judiciously (can cause key collisions)
No #[serde(deny_unknown_fields)] on types that need forward compatibility
No fields or variants named gen — reserved keyword in edition 2024 (use r#gen or rename)

#[derive(sqlx::Type)] enums use consistent representation with serde
Enum variant casing matches between serde ( rename_all) and sqlx ( rename_all)

No fields or enum variants named gen (reserved keyword — use r#gen with #[serde(rename = "gen")] or choose a different name)
Custom Serialize/ Deserialize impls returning impl Trait account for RPIT lifetime capture changes (all in-scope lifetimes captured by default; use + use<'a> for precise control)
Deserialization error paths handle never_type_fallback — ! falls back to ! instead of (), which affects match exhaustiveness on Result<T, !> patterns

Inconsistent rename_all across related types (confusing API)
Missing skip_serializing_if causing null/empty noise in output
deny_unknown_fields on types consumed by evolving APIs (breaks forward compatibility)
Missing round-trip tests for complex enum representations
Field or variant named gen without r#gen escape (edition 2024 compile failure)

Unnecessary #[serde(default)] on required fields
Using string representation for enums when numeric would be more efficient
Verbose custom implementations where derive + attributes suffice
Using #[allow(unused)] instead of #[expect(unused)] for serde-only fields (prefer self-cleaning lint suppression)

Suggestions to switch enum representation for cleaner wire format
Suggestions to add #[non_exhaustive] alongside serde for forward compatibility

Externally tagged enums — serde's default, valid for many use cases
#[serde(untagged)] enums — Valid when discriminated by structure, not by tag
serde_json::Value for dynamic data — Appropriate for truly schema-less fields
#[serde(skip)] on computed fields — Correct for derived/cached values
#[serde(with = "...")] for custom formats — Standard for dates, UUIDs, etc.
r#gen with #[serde(rename = "gen")] — Correct edition 2024 workaround for gen fields in wire formats
+ use<'a> on custom serializer return types — Precise RPIT lifetime capture (edition 2024)