• 从源头去做事件通知 谁改变谁去通知 (并未避免初始化的问题)
• 事件分发两种 异步和同步 同步可能出现连续触发导致诡异的调用层级，异步则可能需要更多的代码检查上下文
• 客户端以服务端时间线为准，那如果时间线客户端先于服务端执行，不可避免的会碰到回滚的问题。但等待服务端时间线执行之后客户端再执行，延迟就会比较高。
• 逻辑与表现分离，对表现来说可以多帧渲染不影响逻辑，对逻辑来说可以跨双端跑。
• 为什么要有我的概念，因为网络游戏两者并不能算是对等实体，其他玩家行为是服务器转发来的合法数据，本地玩家行为是体验优先本地立即响应却不具有一致性的。
• 数据热更要比代码热更来得更加方便，但依旧可能读取不一致的数据出错
• 字面量不具有逻辑，逻辑交由上下文管理，因此是上下文无关的，可以方便在不同逻辑之间做交换
• 字面量之间要做出区分，即需要传给逻辑后表现出多态行为，就得包含自解释数据
• 编辑器编辑策划配置数据要么通过表格的语义来决定，要么就像编程一样通过“元数据”增加表达语义能力，来组织关系
• 事件注册这种异步调用需要注意不同 Entity 上的使用，这种事件监听转换为单次的消息通知，然后自己分发事件监听可以避免异步逻辑
• 组合 ~ 波粒二象性 组合机制
• 继承 ~ 子类能在所有父类上下文中使用
• Python 每一个函数都是一个多态，最好相同的名字有一致的语义，结构性子类型系统依赖于类型中隐式的模式，困难的是维护重要的隐式模式
• Python 多重继承 可以用来解决冲突的问题，但更适合层次需要经常调整的逻辑，一次函数调用就像是走过一个协议栈
• 注意代码（或系统上的）中的相互指涉以及自我指涉，逻辑上的不完备会导致死循环或者悖论导致错误

1. 首先考虑目标是什么，这个目标会有什么性质，这些性质会约束原语语义，以及定下整个框架模型
2. 团队人员需要统一概念，需要有相似的惯用法，这样代码沟通成本会降低
3. 代码风格最后跟语言风格尽量一致，能最大的利用生态，而且就像顺着纹理下刀一样，会更省力

对于实时性要求高的服务器：

• 提前做 准备好做
• 整理做 独立做（减少重复）
• 慢慢做
• 攒批做
• 并行做 事务做 选择策略做
• 不做了（择机再做）延迟做