关于.NET值类型（整数、结构体）访问拷贝规则与赋值问题的技术问询
关于整数自增的内存行为
针对你提到的Dim x As Integer = 10后执行x = x + 1的场景，运行时的实际操作是直接在x原本的栈内存位置完成读写：读出内存里存的10、完成加法计算得到11、再把11写回原来的内存地址。整个过程不会额外分配新的栈空间存11，原位置的10会被直接覆盖更新。
这里需要纠正一个非常常见的认知偏差：所谓“值类型被访问时会返回拷贝”，根本不是“只要读取值类型就自动生成一份独立拷贝”——如果规则真的是这样，哪怕是最基础的整数自增操作都会平白产生不必要的内存开销，完全违背.NET的性能设计目标。
值类型拷贝的真实触发边界
所有会生成值类型拷贝的场景，本质都是需要把值类型的完整内容，传递到一个和原存储位置完全独立的新内存空间时，才会发生拷贝操作。对应你已经理解的已知场景：
- 值类型变量互相赋值：比如
Dim a = 10之后执行b = a，此时b是栈上独立的内存槽位，因此需要把a的值拷贝一份放到b的位置。 - 值类型作为方法参数传入（非按引用传参的情况）：方法的参数会在栈上形成独立的参数槽位，和调用方的原变量内存无关联，因此需要把实参的值拷贝到参数槽中。
- 调用值类型属性/实例方法的返回值时：因为getter方法、普通方法的返回值生成的内容，本身就是存放在独立的临时内存空间里的，和属性所属对象的内部存储没有内存关联。
为什么f.Size.Height = 15这类代码不合法
你之前对“访问”语义的困惑，本质是没搞清楚值类型访问的两层差异：
当访问值类型的路径是直接指向值类型的原始存储位置（比如直接操作栈上的整数变量、直接访问对象内部的值类型字段）时，拿到的是原内存的直接引用，不会生成任何拷贝；只有当访问路径中间经过了会生成临时独立值的操作时，拿到的才是值的临时拷贝。
我们把编译器解析f.Size.Height = 15的完整流程拆开就能完全理解报错原因：
- 从左到右逐层解析表达式：首先拿到引用类型的窗体实例
f，接下来要访问f的Size属性。 - 因为
Size是结构体（值类型）属性，执行它的getter方法时，会返回一个临时生成、完全独立的Size结构体拷贝——这个拷贝和窗体内部真正存储Size值的私有字段没有任何内存关联，哪怕你修改了这个临时拷贝的Height值，等表达式执行完这个临时对象就会被直接丢弃，根本碰不到窗体内部的真实Size数据。 - 正因为这种操作完全没有实际效果，编译器会直接把这类代码判定为语法错误，禁止你给临时拷贝的字段/属性赋值。
对比下来你就会明白，x = x + 1之所以不会触发拷贝、可以直接修改，是因为整个表达式对x的读写，全程都是直接指向栈上x对应的原内存位置——编译器明确知道右边读取的是x的原始值，计算完成的结果要直接写回这个原位置，全程没有经过会生成临时拷贝的中间步骤，因此操作完全合法有效。
补充个实际的正确写法：如果要修改窗体的大小参数，你需要给Size属性做整体赋值，比如f.Size = New Size(15, f.Size.Height)，此时传递的Size对象会通过属性setter直接写入窗体内部的真实存储位置，是合法有效的操作。
内容的提问来源于stack exchange，提问作者Sougata
