ES6单例模式与类单次实例化的对比及优劣分析

Great question! Let's break down these two approaches, their differences, and when to choose each—with a focus on the potential gotchas of the first method you're curious about.

1. 直接导出实例：利用ES模块的天然单例特性 #

Your first example relies on a core feature of ES modules: modules are singletons by default. No matter how many times you import this module, it only executes once, so the API instance you export is the same everywhere in your app.

Pros of this approach #

• Dead-simple usage: Import it and start calling methods immediately—no need to new it every time, which keeps your code clean.
• Guaranteed single instance: Since you don't export the class itself, there's zero chance of someone accidentally creating a duplicate instance by mistake.
• Early initialization: The instance is created when the module loads, so there's no extra overhead the first time you use it.

Potential unforeseen issues (the ones you're asking about) #

This method isn't perfect for every scenario—here are the main tradeoffs to watch for:

• No dynamic configuration: If your API_URL needs to be set at runtime (e.g., based on user settings or environment variables loaded asynchronously), you're stuck. The constructor runs when the module loads, so you can't tweak this.url afterward without modifying the instance directly.
• No flexibility for multiple instances: If you ever need to connect to two different API endpoints (e.g., a staging and production environment at the same time), this approach won't work—you only have one instance.
• Trickier testing: Module-level singletons can persist state between test cases, leading to cross-test contamination. Mocking or resetting the instance requires extra work (like using module mocks or adding a reset method to the class).

2. 传统单例模式：类级别的实例控制 #

The second example implements a classic singleton pattern by storing the instance in a closure and returning it every time the constructor is called. This gives you more control over when and how the instance is created.

Key differences from the first approach #

• Lazy initialization: The instance isn't created until someone calls new API() for the first time. This is useful if initializing the API has heavy overhead, or if you need to wait for some runtime data before setting up.
• Explicit class export: Users have to call new API() to get the instance, but they'll always get the same one. If you later decide you don't want a singleton anymore, you can just remove the instance check in the constructor without changing how consumers use it.
• Theoretical reset ability: While not recommended, you could add a method to reset the instance variable if you need to reinitialize the API (something you can't do easily with the module singleton).

When to choose each approach #

• Go with the module singleton (first method) if:
  • Your API configuration is fixed (no runtime changes needed)
  • You want the simplest possible usage for consumers
  • You don't anticipate needing multiple instances ever
• Go with the class-based singleton (second method) if:
  • You need to delay initialization until runtime
  • You might need to adjust configuration before the instance is created
  • You want the flexibility to drop the singleton constraint later without breaking existing code

Final note #

Don't overcomplicate things! The first method is perfectly safe for most common use cases—its "drawbacks" only matter if your app has specific dynamic or testing needs. For a standard API service with fixed settings, it's actually the cleaner, more idiomatic choice in ES6.

内容的提问来源于stack exchange，提问作者Aaron Balthaser