Go中interface存储的值为何不可寻址？是否源于硬设计假设？
Great question—this is one of those Go design details that feels arbitrary at first glance, but makes total sense once you unpack how interfaces work under the hood. Let’s break this down step by step:
1. Interfaces hold copies, not references
When you assign a value to an interface, Go doesn’t store a reference to the original variable—it stores a copy of that value. Think of it like tucking a duplicate of a document into a folder labeled "interface" instead of just leaving a note with the original document’s location.
If Go let you take the address of this copied value, any changes you made would only affect the copy inside the interface, not the original variable. This would create confusing, unexpected behavior for developers who’d expect addressing to let them modify the source value. To avoid this pitfall, Go simply blocks addressability for all values stored in interfaces.
2. Some values in interfaces are inherently unaddressable
Not all values in Go have a valid memory address. For example:
- Literals like
42or"hello" - Temporary values returned directly by functions (e.g., the int returned by
getCount()) - Inline anonymous structs like
struct{ Name string }{"Alice"}
When you put these unaddressable values into an interface, there’s no valid address to return in the first place. Go could have made exceptions for addressable types, but that would introduce inconsistent behavior—one interface holding a variable lets you take its address, another holding a literal doesn’t. To keep the language simple and predictable, the rule applies universally.
3. Alignment with Go’s value semantics
Go prioritizes value semantics for most core types, and interfaces are no exception. Allowing addressability would blur the line between value and reference types, adding unnecessary complexity. The language designers wanted interfaces to be straightforward: when you pass a value to an interface, you’re passing a copy, and that copy is encapsulated—you can use its methods, but you can’t directly mutate it via an address.
This aligns with the map element unaddressability you referenced: both design choices exist to avoid surprising behavior and keep the language’s semantics clear.
存储在interface中的具体值不可寻址，这与map元素不可寻址的情况相同。
4. Implementation-level constraints
Under the hood, a Go interface is represented by a pair of pointers: one pointing to the type information of the stored value, and another pointing to the value itself. Depending on the value’s size, it might be stored directly in the interface structure (for small types) or on the heap (for larger ones).
If Go allowed addressing this value, it would have to handle edge cases where the value moves (e.g., during garbage collection or heap reallocation), which could lead to dangling pointers or inconsistent memory states. Disallowing addressability avoids these implementation headaches while keeping the language easy to reason about.
内容的提问来源于stack exchange，提问作者Lemurata
