<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>PHP &#8211; HU Xiaoxu</title>
	<atom:link href="https://blog.ihuxu.com/tag/php/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.ihuxu.com</link>
	<description>a software engineer&#039;s blog</description>
	<lastBuildDate>Sat, 21 Jun 2025 02:01:06 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.6.2</generator>
	<item>
		<title>在 Linux 下通过 strace 与 lsof 命令排查 PHP 异常进程</title>
		<link>https://blog.ihuxu.com/php-abnormal-process-investigation/</link>
					<comments>https://blog.ihuxu.com/php-abnormal-process-investigation/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Wed, 30 Nov 2016 03:02:51 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[Foundation]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Operation System]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=9350</guid>

					<description><![CDATA[在有些时候，会遇到 PHP 进程异常卡死的情况。面对这种情况，首先考虑到的就是分析代码进行优化改进，或者重启进程。但是，这种方式来排查不一定能找到根本原因。因为有些时候异常 PHP 进程卡死的原因可能是非常奇葩的问题，比如外部资源异常如 DB、Redis 或第三方 API 等。上一次关于超级话题签到提醒定时任务 PHP 进程异常的处理，问题竟然出现在外部的 DB 的链接上。由于网络原因导致读取 DB 没有响应卡死。 这一次情况比较严重，超级话题积分系统的计算有一部分是通过 Trigger（类似队列）接受全站数据进行积分计算与入库。由于用户反馈问题，来到队列机查看进程情况。如下： 之后，我们查看某个进程的处理日志。如下： 发现进程（pid 10693）在重启之后卡主。 于是利用 strace 查看进程处理过程： 如 strace 信息可以看出，该异常 PHP 进程一直在循环的读取，貌似进入死循环： 接着利用 lsof 来查看该进程的所有链接资源，如下： 所以，可以看出该 PHP 异常进程是在不断的读取 FD 值为 4u 对应的资源，该资源正式 trigger 的服务资源。 通过上述的判断，可以初步断定出现在 trigger 服务上，接着就是找相关部门的人继续深入排查了。 注：已处理敏感信息，如有问题请及时联系站长。]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/php-abnormal-process-investigation/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>自从有了她，再也不怕断签了：超级话题签到提醒</title>
		<link>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/</link>
					<comments>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Tue, 25 Oct 2016 06:24:37 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Technical Summary]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=7394</guid>

					<description><![CDATA[前言 在解决了上一次关于超级话题积分bug后，又接到超级话题签到提醒的产品需求。这是一篇偏于技术实现的文章，讲述的比较笼统，业务围绕超级话题的签到提醒进行展开。如果，您对超级话题签到提醒的技术背景与实现感兴趣，那么这篇文章希望对你有帮助。 当然，如果你是某个超级话题的超级粉丝，比如鹿晗，张艺兴，但是发现断签了。那么我非常替你感到“痛心”，因为目前超级话题没有补签功能。当然，如果你觉得是因为系统问题导致没有连续签到，那么你可以通过超级话题的官方反馈方式进行反馈来解决问题。当然，我劝你这么做之前一定要三思。因为，通过我排查的经验而言，基本山是由于你们（用户）把时间搞错了，而导致没有续签。而且，目前的签到提醒功能会在每天晚上提醒你签到的哦~ 产品 最近，在忙活超级话题的签到提醒产品的开发。首先，这是第一次比较热切的关注用户反应的产品。虽然说，对于产品的参与和认知并没有多么深入的理解，但是愈发的觉得这件事很有意识，也更想参与其中。 超级话题打破了传统话题的模式，以社区的形式展现，提高用户互动与粘性。其中，签到是不可或缺的一项功能。然而在前期，签到功能在给用户带来了高回访的情况下，也有着苦恼。作为研发同学，更是备受折磨。为什么？产品总是拿着反馈中自称经签过但却莫名断签的用户ID找我排查问题所在。然而，几乎都是一些凌晨时分签到而次日未签的情形。尽管是这样，用户的反感也是无法消除的。 为了不再做反复的排查劳动，只好做了一个相关查询后台。 产品同学为了召回用户，提供话题的UV和PV，提出了签到提醒的概念。 签到提醒会根据当前用户的签到行为，进行提醒私信的推送。目前为止，基本上每日需要提醒的量大约在85w左右。然而，在发送私信的过程中并非如此顺利。 技术 首先，要进行数据的准备。利用crontab定时将DB中的数据写入磁盘文件。之所以这么做，主要是由于DB中的数据是动态的，需要将数据写成静态的形式以更好的分批处理。 然仍采用crontab定时启动发送私信的脚本。将启动n个进程，同时处理上述步骤生成的n个文件。以curl_multi的方式批量调用话题粉丝服务的内部接口。 数据 超级话题提醒私信下发量：85W/日 超级话题提醒倒流UV：可观 下面的Redis服务中Key的曲线图，可以约等于下发的私信量： 问题 在形成上面的技术流程之前，也是经过了几番周折。 最初，以单进程的方式直接从DB读取数据，单次调用粉丝服务的接口进行发送私信。然而，在这种情况下，每日（2.5个小时）却只能发送5-6w的私信量。 由于压力主要在外部粉丝服务接口上，所以采取了批量调用的方式。利用PHP中的curl_multi，逢10批量调用粉丝服务接口。这样下来，每日（5.5个小时）能发送51w左右的私信。 然而，还是不能满足近100w的私信调用量。所以，增加了数据准备阶段。将数据写成静态文件，以多个进程的形式，同时处理文件以批量调用粉丝服务接口来发送私信。 在功能上线的第一天晚间，观察处理文件的进程“卡死”。 从上面两图可以确定，PHP进程卡死的原因在于读取MySQL服务中。进过排查处理后，程序得以进入正常流程。 目前为止，每日的调用量完全可以满足所需要发送的私信量。 用户 用户对签到提醒的反馈还是非常不错的，有图为证： 总结 针对于这种需要长时间运行与调用外部资源的脚本，最重要的就行要进行好完善的异常处理机制。由于PHP脚本的异常处理并非强制的，如果处理不妥到，会导致进程直接终止，排查起来也很困难。 同时，对于相关资源的监控也很重要。比如，当前机器的CPU资源，接口的平均响应时间，DB服务的相应时间等等。以确定每次执行期间相关资源的健康状态。]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/check-in-push-for-super-topic-at-weibo/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>PHP 的 Traits：到底是祸害还是好得飞起？</title>
		<link>https://blog.ihuxu.com/php-traits-good-or-bad/</link>
					<comments>https://blog.ihuxu.com/php-traits-good-or-bad/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Wed, 12 Oct 2016 11:31:27 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[Traits]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=6479</guid>

					<description><![CDATA[在 2012 年 3 月初，PHP 团队宣布了 5.4 版本的发布。程序员们对这次的发布已期待许久，因为这一次的升级带来了很多特性的加入。其中，最受追捧的是 Traits。为了构建这次发布的版本，Shammer C 特意为此撰写了一篇文档：如何使用 PHP 的 Traits，我强烈的建议您在读这篇文章之前拜读一下，因为这篇文章需要读者能够对 Traits 有一定的基础了解。 Traits 已经被 PHP 社区广泛的接受，最为关键的是因为它包含了其他 Java、C++ 和 Python 编程语言的特性。除此之外，Traits 也被广大的网友们神化了。那些程序员狂砍这种特性将给他们的项目带来多么大的益处，尤其指出它是能够替代面向对象（OOP）继承的特性。然而，Traits 真的有那么神奇么？难道真的能对 PHP 开发有所促进么？还是败絮其中呢？ PHP 的 Traits 是个祸害 从表面上来看，由于它可以降低整个应用中代码的复用成本而受到了非常强烈的支持。此外，它仍然可以帮你提高代码的可维护性，并看起来更简洁。 尽管 Traits 是那么的受欢迎，但是许多高级程序员却担心将来的情况并不会像当初设计的那样。高级程序员 Anthony Ferrara 担心它将会变成下一代被滥用的功能，像 evel 和 constants 那样。但在此之前，Anthony 曾提出了一个有趣的观点：Traits 其实是一个没有 state 的 Mixins 的具体集合。PHP 中的 Traints 支持 state 的使用。所以，PHP 的 Traints 实际就是 Mixins。这个简单的观点说明了 PHP Traits 的最终真实的意图，其实就是“挂着羊皮卖狗肉”。更不用解释为什么会以 Mixins 的形式，而不是以全球公认的无 state 的 Mixins 形式来处理（很抱歉，我都没明白是啥意思，看来还得深入了解下）。 Anthony 继续讲到，使用 Traints<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/php-traits-good-or-bad/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/php-traits-good-or-bad/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>基于 libgit2 C 语言库的 php-git 扩展 fix bug 辛酸史</title>
		<link>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/</link>
					<comments>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/#comments</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sat, 27 Aug 2016 09:41:31 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[C]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[PHP Extension]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=1181</guid>

					<description><![CDATA[前言 这是一篇极其没有节（nei）操（rong）的文章。除非你真的无聊，请不要阅读，否则后果自负~ 正文 最近，在忙活微博话题组的日构建工具。工具主要的功能并不算复杂。写着写着，外面雨过天晴，居然还放起爆竹了，什么鬼。 构建工具的主要功能正如介绍中所述的那样，提取产品、测试等基本信息、提取版本库（git）信息、检查（编译）源文件、自动部署项目与发送邮件等。在提取 git 库信息时，相对于之前利用 shell_exec PHP 原生函数提取 svn 信息的方式，打算利用扩展来提取信息。一来更规范、更有效率（微乎其微），二来专业。缺点是相对而言部署环境麻烦，因为需要安装 git 扩展到当前 php 运行环境中来。 但是，万万没想到官方推荐的 php-git 扩展库开发版本已有3年没有维护了。索性用吧，又能怎样。 安装 还算顺利，由于公司开发机没有 cmake，yum 源也不可用，懒得配置，直接 download 一套源码。 上述步骤自行领会，注意上述适用于 64 位 Linux 系统，32 位的 Linux 请见上述提到的 php-git 库说明文档。 使用 我们提取的 git 信息基本也就是从上一次部署版本，到该次部署版本之间的 log 和 diff 信息。所以，第一件事情，就是拿到这段的 commit hash 值。关于下文中提到的 commit hash 和 tree hash 概念可以自行 google 或参见博客libgit2使用教程（特别篇）几个基本概念说明。 在拿到 commit hash 之后，将通过 git_diff_tree_to_tree 方法拿到每个 commit hash 之间的 diff 信息。通过方法名可以知道，这个 diff 信息是通过两个 tree 拿到的。 调用代码：<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/the-experience-of-the-fixing-libgit2-git-diff-tree-to-tree-bug/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>关于“如何开发 PHP 扩展”的学习小结</title>
		<link>https://blog.ihuxu.com/the-summary-of-the-php-extension-learing/</link>
					<comments>https://blog.ihuxu.com/the-summary-of-the-php-extension-learing/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Tue, 08 Mar 2016 09:28:37 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[PHP Extension]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=763</guid>

					<description><![CDATA[近期，工作上的业务并不是很忙。做了大半年的业务逻辑，尽管在 PHP 编码习惯和技巧上有所进步，初步熟悉了在高并发下 Redis 和 Memcache 缓存的使用和注意事项。但，应该借此闲暇时间探索下 PHP 底层的一些原理。这样，才是会有质的提升，写出更好的代码。 正如那句话“PHP 取得成功的一个主要原因之一是她拥有大量的可用扩展”，那就从 PHP 扩展入手了解下。 在此之前，大家肯定都了解“PHP 是 C 写的”。于是打开了 PHP 的源码，列出跟目录列表如下图： PHP（5.6.4）跟目录列表 看到了熟悉的以后缀 .c 结尾的源文件。如图，有个名为“Zend”的文件夹很重要，这个就是 PHP 的核心。于是在网上搜到了两个若干 PHP 扩展的教程： http://www.laruence.com/2009/04/28/719.html http://www.walu.cc/phpbook 起初，耐心的看了 http://www.walu.cc/phpbook 的教程。并没有读完，只是看了前面的前 8 章。之后按着 http://www.laruence.com/2009/04/28/719.html 的教程，仿照着写了一个扩展。进行了编译、排查错误、编译、安装和测试等步骤，有了整体的感知。 在开发的过程中，可贵的也是难点就是要遵循 PHP 的扩展开发标准来做。我想，只要是熟悉了这个标准，至少写出一些简单的扩展是 OK 的了。在此基础上，继续深入的了解其特性，才可以开发出稳定、安全且高性能的扩展吧。 上述提到的源码（供学习交流之用）：http://github.com/genialx/geno_file]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/the-summary-of-the-php-extension-learing/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>PHP 数组函数 array_diff()、array_merge() 与数组操作符 +</title>
		<link>https://blog.ihuxu.com/php-array-diff-array-merge/</link>
					<comments>https://blog.ihuxu.com/php-array-diff-array-merge/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Thu, 10 Dec 2015 08:56:21 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=564</guid>

					<description><![CDATA[array_diff() 函数是以值为判断依据，比如： 输出： 同样，array_merge 函数也是以值为判断依据进行合并数组，如下： 输出: 问题来了，如果利用数组操作符 +，进行两个数组的合并，却是以键为判断依据： 输出：]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/php-array-diff-array-merge/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>利用 xhprof（PHP）扩展进行 WEB 性能分析</title>
		<link>https://blog.ihuxu.com/web-performance-analysis-using-php-xhprof/</link>
					<comments>https://blog.ihuxu.com/web-performance-analysis-using-php-xhprof/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sat, 05 Dec 2015 13:37:41 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[XHPROF]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=512</guid>

					<description><![CDATA[最近工作有些小忙，经常加班，偶尔还会通宵。但最终热门微博“混合流”顺利地全量上线了。可是，从性能角度来说，还是有不少的提升空间的。 下面说下利用 xhprof 来进行 WEB 性能的分析。 安装 xhprof 扩展 官方的文档胜过一切 =&#62; http://php.net/xhprof 注意：如果想利用 xhprof 绘图，那么需要将系统默认禁用函数打开。 部署xhprof的运行环境 经过上面的配置，在你跑过项目后，xhprof 会输出一份报告文件。不过，这份文件的内容是被序列化的数组。所以，需要搭建一个能够读取该数据文件的 WEB 环境。 这里给一份 xhprof 环境的代码：http://pan.baidu.com/s/1bnLvmrl 之后通过访问 xhprof 的环境，你会看到如下报告界面。 xhprof 文件列表（/xhprof_html/list.php） 图标形式的 xhprof 报告(/xhprof_html/index.php） Function Name 方法名称 Calls 被调用次数 Incl. Wall Time 该函数执行时间（包含内部其他函数调用的时间） Excl. Wall Time 该函数执行时间（不包含内部其他函数调用的时间） 流程图形式的xhprof报告（/xhprof_html/callgraph.php） 需要关注的几点： 同一方法被过多次的调用（也许是无谓的循环导致的） 耗时是否落到了外部接口上（会影响TPS &#8211; 每秒请求数量） 是否有内存的过多消耗（会影响计算效率）]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/web-performance-analysis-using-php-xhprof/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>高并发场景下的缓存使用误区</title>
		<link>https://blog.ihuxu.com/the-cache-usage-errors-in-high-concurrency-scenarios/</link>
					<comments>https://blog.ihuxu.com/the-cache-usage-errors-in-high-concurrency-scenarios/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Thu, 08 Oct 2015 05:03:33 +0000</pubDate>
				<category><![CDATA[Computer Language]]></category>
		<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Memcached]]></category>
		<category><![CDATA[Middleware]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Redis]]></category>
		<category><![CDATA[Original]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=402</guid>

					<description><![CDATA[十一聚会，某谈及人生理想。我要的是“地位，身份和爱情！”，其实就是金钱，面子和美女。O.O 正文 9月份，连续两天（AB 两天）线上出现业务故障，redis 监控曲线瞬间上涨。 业务场景：一千万 UV / 日 redis监控曲线 （修改图片好麻烦，曲线意会下吧~）： redis日志 业务代码 &#160; 问题 由业务代码和redis日志可以看出，正常情况下通常会有一次删和一次写之后，会出现大量的读。然而，日志中则出现了大量的写入。这就是高并发时导致同时写入后，也许因为写入量特大，导致下次读取失败后继续进行写入，最后把 redis 拖垮。 解决 如果不需要进行排序截取等操作可以换用 Memcached 缓存 在高并发情况下应对 redis 加事务机制 redis事务 修改后的业务代码 注：封面配图为朋友圈图片]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/the-cache-usage-errors-in-high-concurrency-scenarios/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>微信支付 JSAPI 开发中的问题</title>
		<link>https://blog.ihuxu.com/wechat-pay-sdk-development/</link>
					<comments>https://blog.ihuxu.com/wechat-pay-sdk-development/#respond</comments>
		
		<dc:creator><![CDATA[HU Xiaoxu]]></dc:creator>
		<pubDate>Sun, 23 Nov 2014 15:15:13 +0000</pubDate>
				<category><![CDATA[Computer Science]]></category>
		<category><![CDATA[Dev Problem]]></category>
		<category><![CDATA[Original]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[SDK]]></category>
		<category><![CDATA[WeChat]]></category>
		<guid isPermaLink="false">http://www.ihuxu.com/blog/?p=89</guid>

					<description><![CDATA[前言：这篇文章讲的是利用微信官方提供的 JSAPI 接口，实现微信网页支付。希望在看之前，要确认以下几件事情，否则会在解决问题时很费解。 ①　接口文档版本号是 V3.3（在官方提供的 PHP DEMO 中的 README.txt 文件中查看。当然，也可以参考压缩包的名字（wxm-payment-biz-api218f8e.zip）来确认版本 ②　微信支付 PDF 文档的版本为 V3.3.7（如果上述版本对了，这步应该也是一致的，因为这两个文件是在一个包里） ③　该文章说的是 JSAPI 的开发 简单看了下微信支付的文档和源码（压缩包名：wxm-payment-biz-api218f8e.zip；PDF 文档名：【微信支付】微信公众号支付接口文档V3.3.7.pdf；）。然后，修改了微信的配置文件。有如下几个配置项值得注意： 1、 MCHID 注释是“受理商 ID，身份标识”。可以在邮件中查看，这个邮件是在申请支付的某个流程中回执的。由于我不是微信号的“主人”，所以具体在哪个环节不好确定。同时，邮件中还会有个密码。利用这个 MCHID 和密码可以到微信商户平台（https://pay.weixin.qq.com/）登录，进入管理商户订单的界面。 2、 KEY&#160; 这个 KEY 有些苦逼啊，文档注释说是“商户支付密钥 Key。审核通过后，在微信发送的邮件中查看”。但并没有在邮件里找到这个 KEY ！算了，百度了下，发现是在微信商户平台设置的。利用上面提到的账户信息登录商户平台后，点击左侧的“安全设置”（记不清了，如果不是这个关键字，找到证书管理的选项即可），然后需要安装浏览器证书插件后，手动设置这个 KEY。随意设置，可以用 MD5 加密后的字符串，比如 MD5(&#8220;Foo&#8221;)。 3、 SSLCERT_PATH 注释为“证书路径，注意应该填写绝对路径”，给的默认格式为“/xxx/xxx/xxx/WxPayPubHelper/cacert/apiclient_cert.pem”。但是，我直接用的“http://www.domain.com/wxpay/cacert/apiclient_cert.pem”这种格式。因为，简单看了下利用这个常量的调用代码，用的是 Curl 函数，那么我想用 http 开头的链接应该不会有问题了。 4、 SSLKEY_PATH 同上 5、 CURL_TIMEOUT&#160; 这个常量在这个版本的 DEMO 中没有用到，直接写的 30，开发者注意修改。 刚才介绍了几个有歧义的常量，下面还有个问题需要注意。在 WxPayPubHelper.php 文件中的第155行的常量有拼写错误。 官方的文档我很无语哦！&#160;：《 好了，配置项 OK 了。程序部署到网站的 wxpay 项目下(http://www.domain.com/wxpay/)。然后在微信公众号管理后台的微信支付的界面中进行了支付授权目录的设置。设置后不知道为什么显示为空，我没有注意。同时，我在支付测试目录中也设置了路径，同时把测试号的微信 ID 填入白名单。 这时，测试的时候一直提示 system:access_denied（同：system:not_allowed）。 接着，仔细看了下 PDF 文档，觉得问题出现在支付授权目录下，果不其然。切记，阅读官方文档是多么的重要！ 解决步骤：把测试账号的微信 ID<div class="read-more"><a class="btn read-more-btn" href="https://blog.ihuxu.com/wechat-pay-sdk-development/">Read More</a></div>]]></description>
		
					<wfw:commentRss>https://blog.ihuxu.com/wechat-pay-sdk-development/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
