类变量与实例变量：Scrapy/Django中使用类变量的原因探究

Great question! I’ve had this exact confusion when I first started working with Scrapy and Django ORM too—let’s break this down step by step to understand why class variables are the right choice here.

1. Frameworks Need Metadata Before Creating Instances #

First and foremost: Scrapy and Django need to know about your data structure before you even create an instance of the Item or Model.

Think about it: Django needs to generate database tables, run migrations, and validate data against field rules. Scrapy needs to validate scraped data, export items to formats like CSV/JSON, and handle field-specific processing. None of this can happen if fields are only defined inside __init__ (as instance variables)—because instance variables only exist after you create an object.

Class variables, on the other hand, exist as soon as the class is defined. Frameworks can scan the class’s attributes at startup to collect all field metadata (like names, validators, and data types) and use that to power their core features.

2. Declarative Syntax is Cleaner and More Readable #

The class variable syntax is designed to be declarative—you write what your data structure looks like, not how to build it. Compare:

# Clean, declarative class variable approach
class CustomItem(Item):
    one_field = Field(validators=[RegexValidator(r'^\w+$')])
    price = Field(output_processor=TakeFirst())

To the messy alternative with instance variables:

# Clunky, imperative instance variable approach
class BadCustomItem(Item):
    def __init__(self, one_field, price):
        self.one_field_config = Field(validators=[RegexValidator(r'^\w+$')])
        self.price_config = Field(output_processor=TakeFirst())
        self.one_field = one_field
        self.price = price

The first example lets you glance at the class and immediately understand its structure. The second hides field configurations inside a method, makes code redundant, and is a nightmare to maintain.

3. Metaclasses Do the Heavy Lifting #

Behind the scenes, both Scrapy’s Item and Django’s Model use metaclasses—special classes that control how other classes are created.

When you define your Item/Model class, the metaclass scans all class variables that are Field instances. It collects these fields into a shared metadata store (like Django’s _meta attribute or Scrapy’s fields attribute) and then handles translating that metadata into instance behavior.

When you create an instance (e.g., CustomItem(one_field="hello")), the framework doesn’t use the class’s Field instance directly—it uses the metadata to initialize the instance’s data attributes. So even though the Field is a class variable, each instance gets its own unique value for the field.

4. Shared Configuration Makes Sense #

The Field instances in your class variables aren’t storing instance data—they’re storing configuration for the field. Things like validators, default values, or processing rules should be the same for every instance of your Item/Model. Using class variables lets you define this configuration once, and all instances inherit it automatically. No need to repeat the same field settings in every __init__ call!

What If We Switched to Instance Variables? #

Short answer: It won’t work with these frameworks, and it’s a bad idea even if you hacked it together.

• Frameworks can’t access field metadata upfront: Django can’t generate database tables, Scrapy can’t validate or export data.
• Code becomes repetitive: You’d have to redefine field configurations in every instance’s __init__, leading to bugs and maintenance headaches.
• You lose the declarative syntax: Your data structure’s definition is no longer clear and centralized.

For example, if you tried to define a Scrapy Item with instance variables, Scrapy would have no idea what fields your item has—so when you try to export items to a CSV, it would write nothing, and field validation would fail entirely.

内容的提问来源于stack exchange，提问作者Dawid Gacek