升维思维：关注客体与环境的交互，寻找降维升维之间的"度"

相比[[降维打击：压缩时间空间维度，及降维建模的主客体二元组|降维思维关注主体与客体的交互]]，升维思维重点关注客体与其运行环境之间的交互——客体的运行会受环境影响和约束，所以考虑客体时不能只看客体自身，还要结合环境全面考虑。编程中最容易写出的是正常业务逻辑，但结合环境因素后还要考虑异常逻辑处理——”正常逻辑+异常逻辑”就是典型的升维思维。架构设计中，针对非功能性需求设计出具体方案只是”一阶思维”，升维思维要求进一步追问：系统周边环境可能有哪些反馈？某个环节的性能提升会不会引发另一环节的性能下降？以缓存解决高并发热点数据存取为例：引入缓存后要问”缓存挂了怎么办、会不会影响整体高可用”，这个问题可以用缓存+数据库两级存储解决；但两级存储又可能带来缓存穿透问题，需要再引入限流或布隆过滤器——只有把系统和环境因素综合起来考虑，才能得出更全面有效的方案，这正是升维思维层层递进的体现。把降维（关注主体客体交互）和升维（关注客体环境交互）结合起来，能得到更完整的系统认知：任何系统在特定环境下都存在一个最适合的处理范围（准度、精度、大小、边界等），找到降维和升维思维的结合点，就是找到处理当前问题最好的”度”——多一点或少一点都可能带来效率、成本、沟通等问题。比如业务架构建模阶段如果提前引入技术实现细节这类不该关注的内容，模型会失去聚焦性、增加大量沟通成本——DDD战略设计阶段划分领域/子领域，只需要关注”领域”这个度，暂时不用关注限界上下文或聚合的度。可迁移启发：设计一个方案时，与其无止境地”再往下多想一层可能出问题的地方”，不如先明确当前阶段该锁定在哪个”度”上——过度升维（想太多层环境反馈）和过度降维（一步到位简化掉本该关注的细节）同样都是资源浪费，关键是让思考深度与当前阶段真正需要解决的问题相匹配。

结构图：

flowchart TB
  D["降维:主体↔客体交互"]
  U["升维:客体↔环境交互"]
  U --> E["示例:缓存解决高并发<br/>→缓存挂了怎么办(升维1)<br/>→两级存储→缓存穿透(升维2)<br/>→限流/布隆过滤器"]
  D --> F["结合降维与升维=找到处理问题的'度'"]
  U --> F
  F --> G["度过深/过浅都造成效率/成本/沟通浪费<br/>(如业务架构建模阶段不该关注技术细节)"]