最近在写js的时候遇见一个奇怪的问题

$(select).html(某些元素);
$(某些元素).on(一些事件);

上面这两行代码很简单，第一行就是给原定元素增加一些新元素，第二行是对这些新增加的元素绑定一些事件。但是在多次运行的时候会偶尔出现问题，总会发生几次html(某些元素)还没有写完“某些元素”，第二行的on(一些事件)就执行了。此时因为html()还没完成，所以那些元素还不在页面上，所以第二句$(某些元素)找不到对象报错。

简单说就是第一行的html()还没完成，第二行的on()就执行了。实际上不管第二行是on()也好css()也好，都会发生这种提前执行的情况。

在网上问了一圈，有人提到用on()的事件代理可以解决

$(select).on( events [, selector ] [, data ], handler )

selector

Type: String

A selector string to filter the descendants of the selected elements that trigger the event. If the selector is null or omitted, the event is always triggered when it reaches the selected element.

https://api.jquery.com/on/

已有父节点A，要在父元素里创建子节点B并给B绑定事件。可以把事件绑定到A上，就是楼上说的事件代理。

假设A的class名为parent，B的class名为child，就可以这样写:

$(‘.parent’).on(‘click’, ‘.child’, 事件).append(‘<div class=”child”></div>’);

但是有一个进阶问题，当第二行是css()的时候无事件可以绑定，即无法使用on的时候怎么办。对此网上也有如下解释

这个问题虽然很常见, 但是产生原因很底层. 就是浏览器的DOM元素更新和JS的执行并不一致, 如果想要等待DOM真正更新完成再执行下一步操作, 那么就必须监听DOM元素在浏览器的更新是否完成, 再执行下一步操作

是真正想解决这个问题可能要用到MutationObserver或者MessageChannel等API, 其中还涉及到浏览器兼容性问题, 楼主有兴趣可以钻研一下.

没兴趣的话, 用Vue等前端框架重构一下, 框架提供了大量方便的方法来实现类似功能.

到目前我能想到一个办法，虽然有点蠢，但确实有效。利用setInterval设置一个定时器，在html()后不断检测新增加的元素，一直到检测到该元素再执行后面的内容。

$(select).html(new ele + "<div id='EndFlag'></div>")
//我不确定上面这种写法是否能行，总之就是在新增的元素中增加或者选取一个标识符
let t = setInterval(function () {
        let end = $("#EndFlag");
        if (end.length > 0){
            clearInterval(t);
            do whatever you want
        }
    }, 1000)

从第一集的惊艳到现在已经第三季了，怎么说呢，不能说是质量下降吧，只是感觉最开始的一些内在的东西已经少了。

首先肉眼可见的是CG的动画已经成了绝对主要组成部分，大量电影级的CG表现几乎是这一季能给你的最直观的印象。但是这些精美的CG在表现什么内容呢？有些则显得非常的干瘪。尤其是一些类似，因为时长很短我只能说是类似惊悚电影桥段的的CG表演显得毫无内容。比如这一季的虫族和隧道坟墓，前者除了表现CG能力强大对各种节肢类动物的描绘栩栩如生以外，无非就是一个虫族利用人类的自大而报复人类的故事。结尾女主造型过于惊悚，也是唯一能观众留下的印象。后者就是一个典型克苏鲁小故事，用CG吓人这方面倒是做足了功夫，角色的死亡的凄惨镜像利用CG表现的淋漓尽致。

尤其是最后一集，说实话看的让人莫名其妙。我甚至无法分辨这到底是算是动画还是真人短篇。应该是一个神话故事，但是摇晃的镜头加上意义不明的画面我实在无法理解这有啥好看的。

这是一篇手记，实际上我在刚才为标题这个事情折腾了好几天，网上查了无数资料，最终终于成功。然后我发现网上的几乎所有资料都存在或多或少的确实，一些问题没有提到。所以如果有人和我一样卡在这个过程中的某个位置，请参考一下我在这里列举的一些情况是否对你有帮助。

这里需要再次说明，我会将整个过程写出来，网上已经有了太多的资料，本文章只是对这个过程的补充。

问题1

这是最坑爹的一个，简直了。我们都知道需要xdebug这个php插件，事实上xampp都有自带这个插件，但是问题来了。在php.ini中的配置真的配对了吗？坑点在这里：

extension=php_xdebug-2.7.2-7.1-vc14-x86_64.dll //这样是错的
zend_extension=D:\xampp\php\ext\php_xdebug-2.7.2-7.1-vc14-x86_64.dll//这样是对的

问题点在于不能用extension，要用zend_extension，而且二者不能同时出现。这个问题你无法通过phpinfor()发现，只能通过php.exe -m或者php –version获得两个waring。如果无视这个问题，在phpstorm中debug无法获得任何信息，断点无效，始终处于“正在等待与ide key 的传入连接”。

Warning: Xdebug MUST be loaded as a Zend extension in Unknown on line 0
Warning: Module 'xdebug' already loaded in Unknown on line 0

问题2

在php.ini配置完成后，在运行配置里验证一下，有些问题就暴露出来了，比如网上很多地方都写着：

xdebug.remote_handler = "dbgp"

这么写真的对吗？通过验证看一下，有没有报错

问题3

这个问题网上有提到，就是PHP环境配置里PHP语言级别和CLI解释器不一致的情况。我想有可能这个问题出自官方，因为官方教程中有这样一张图。

其实很明显，这样的话是有可能在debug时接收不到信息的，将语言级别和CLI解释器的语言级别调整为一致是必要的。

我做了一个小品级游戏的DEMO，类型是黑客模拟类，或者也可以叫剧情解密类，亦或者叫它打字游戏也行。如果你玩过《Hacknet》或者《NITE TEAM 4》应该能立刻理解。游戏设定了一些原创的计算机命令，玩家通过输入不同的命令达到推进游戏进程的目的。

这个DEMO展示了我对游戏的基本概念，抛弃计算机屏幕内容以外的其他元素，让玩家能够专注于一个电脑专家本质的体验。当然，对于游戏来说过于繁琐的输入和计算机原理不具备娱乐要素，仅此我们尽量精简。用简单的操作来讲个好故事。

目前的设想

需要一个优秀的剧情，核心玩法虽然是打字输入，但我深刻的明白游戏能够提供的游玩动力是剧情。因此我需要一个会讲故事的伙伴来加入。

炫酷的FUI，玩过都都知道简单或者说捡漏的UI界面非常没有卖相，让人一眼看上去就不想玩。而这种游戏玩家面对的几乎100%都是这个UI界面，所以高质量的UI设计是游戏出色的基础。

美术资源依然需求，目前DEMO中所使用的图片全部来自网络，实际上在我的设想内，游戏在外来如果可能希望能够加入一些动画。

配音，现在此类游戏已经有一些进行了配音，效果拔群。与其看界面上如聊天记录一样的文字叙述剧情，适当的配音能让游戏的效果更好。

期待各位的加入，请在下面留下联系方式！

如有什么想对我说的也请在下面留言！

无论是《摇曳露营》还是其他视频中所展现的露营都是其中最美好的一面。露营确实很好玩，一群人玩的很high，K歌也好，看电影也好，打游戏也好，一起烧烤也好，能够留在记忆中的都是各种美好的影像。于是我在回来后，整整缓了一天后才有力气打开笔记本记录这一切。

本来以为是一趟说走就走的旅程，于是在几乎没有计划的前提下，趁着双12网购了一切物品。一起去的人中，有一个极富经验的哥们，想着能准备的都准备了应该问题不大。然而，天时地利人和，从最开始就只剩人和了。什么叫只剩人和，就是靠自己。计划永远赶不上变化大，当我们到达露营目的地的时候天都黑了。于是只能开始抹黑搭帐篷，第一次啊，以前虽然也搭过简易帐篷心想问题不大，于是买的是那种相对复杂一点的帐篷，结果就吃瘪了。露营目的地是在水边，地面土厚也就2-3厘米，下面全是碎石子。帐篷的第一根钉子都打不进去，当费了半条命终于打下第一颗钉厚绝望的发现这样的钉子一共要打18根。于是在放弃了地面定位钉厚，只打了剩下的9根防风钉，勉强把帐篷搭了起来。然后我就彻底摊在座椅上了，感觉双手要废掉。咬着牙切着齿，把桌椅板凳，床垫睡袋全部铺好后，都快十点了。旁边那家有钱人开着房车，饭都吃完了，我们这边才开始煮火锅。

不过，后面迎来的是欢乐的时光。一群人吃着火锅唱着歌，烤着烧烤打着游戏。能够享受着一切，忽然又觉得前面的努力都值得。一群人疯到深夜，终于熬不住了，钻帐篷睡觉。还好选的帐篷是棉布的，这里晚上零度左右，厚实的睡袋加上自己的棉衣，一晚上下来不算冷，倒是热醒了一次。

第二天起来就又要开始干活了，把所有睡袋和床垫压干空气装进小袋子里就又费尽了所有力气，然后是拆帐篷，折叠所有家具，打包装箱。当我坐上车的时候，感觉自己已经一动都不想动了。

其实后来想起来，我对所有露营设备的设计都有了深刻的理解。为什么要设计的这么简单，为的就是减少旅行的人在架设营地的过程中花费的力气。但即便如此，所付出的劳动依然不是没经历过的人所能理解的。不要被网上那些影片和动画里的画面骗了啊，很多人在经历过这些以后，都不会再去搭帐篷了。而对于以后的露营计划，我也需要再好好考虑一下。

本质上是塔防游戏，增加了RTS要素，算是这一类游戏中出类拔萃的了。玩家需要不断建立自己的防线，因为僵尸总是从四面八方过来，哪怕是一个最小的僵尸，如果进入基地那一切就都完了。所以游戏正常的推进方式应该是，玩家利用地形不断的建设自己的防线，设置岗哨和巡逻的卫兵。而尸潮涌动意味着地图外会有大批僵尸过来，这意味着玩家建立的最外围防线可能是守不住的，于是后方早期建立的城墙成了战略后撤的新防线。虽然是个纯2D的游戏，但是看着乌央乌央的大群僵尸涌过来，还是十分震撼的。

另一点，游戏在地形上的斟酌是非常重要的，不同的地形适用于不同的资源获取。房子占了绿地就意味着农场或者狩猎屋将无处安放。可以这么说资源的管理是游戏最重要的环节之一，玩家可能建立了占据地图的大片面积的基地就位供养数量有限的军队。而这些军队在尸潮涌动时，又会发挥至关重要的作用。这导致在玩到后面，玩家会发现很多建筑物的摆放都是有讲究的。

不过游戏有个很明显的问题在于没有快进选项。当然我明白，这款游戏的节奏掌握的还是很紧凑的，玩家所做的事情都必须抓紧时间。如果尸潮到来前没有准备好那迎来的必定是game over。但也会出现另一种情况，比如在简单难度下，当玩家做好一切准备来测试自己的防线时，距离游戏设定尸潮涌动的日期还有一段时间，那么接下来玩家能做的就只能等。说到这里，最近出的类似的游戏《最后防线》就明显做的更好，毕竟是老游戏也无法强求吧。