境内的小程序在境外使用微信支付，支付人民币后收款方直接转换成外币，可以实现吗？

想开发一个小程序，用户受众为国外留学生，有支付功能，希望使用外币（英镑）支付，国内主体可以吗

[图片] 例图： 美工用画布，762 px 宽度 标示了每个文字和边框之间的间距。但实际上小程序适配不同手机的时候，可能会有些差别。 虽然目前用了 rpx 和百分百的模式进行布局。视觉第一感觉上一致了。 如果说完全百分百还原，那肯定是没底的，几乎都是一点点试出来的，感觉高一点，就减少个rpx，矮了，就加一个rpx。 实际上并没有完全理解多少 rpx 才是真实还原视图. 想得到一个答案？求教

我是个美工，日常工作的第一职责是负责把“火箭”漂漂亮亮地画在微信小程序上，然后让开发实现出来；然后第二职责是指着 1px 挑刺儿：“有这么难吗？我又不是没写过 hello world。” 想自己写个小程序不是一天两天了。正赶上快过年了，就用这个书法拜年的小程序练练手。 这个小程序的想法其实很简单，就是让用户用手指在屏幕上写书法的福字。为了丰富一些玩法，就加入了一些其他的拜年吉祥话的字帖，以及一些不同颜色的主题，并且把这些放在后端，更新起来更灵活一些。 整个开发过程中最复杂的其实是这个毛笔笔刷，因为小程序只能返回用户手指的 x 和 y，所以我只能通过这两个值和 touchmove 的时间差，来模拟毛笔的笔触：包括运笔、提笔以及最能代表毛笔特征的飞白效果。在研究了其他产品上的笔刷实现之后，并没有找到在不依赖按压力度的情况下，只依靠 x, y 来实现所有这些效果的案例。那只能自己搞了。于是经过一个多礼拜反复修改计算方案、调参数，最终的实现效果自己还挺满意的（虽然上手有一定难度）。 [图片] 可以扫码体验 [图片] 虽然笔刷是这个小程序里最重要的部分，但不是我花时间最多的。那时间都去哪了？都掉在下面这几个坑里了…… 第 0 坑：我就不用框架。框架是什么？能吃吗？ 从一开始，我就打算纯手敲一个小程序，不用框架。 三个原因： 我搞不懂框架，要花时间去学习我觉得框架都很冗杂、臃肿，要为有限的便捷性牺牲灵活性（反正我做的又不是大项目）我爱造轮子！纯手敲小程序其实也没啥坑，硬要说带来的最大的坑就是：需要造不少轮子。但谁让我乐意呢。 作为新手，做一些简单的基础组件，再包成业务组件，再用到实际的业务场景，这整个过程其实挺健脑的。比如，写个 button 组件，用来处理样式、状态、事件；然后包进 button-group，用来处理布局；然后被包进 dialog 或者 form 用来处理点击后的统一行为（比如关闭、提交）；最后被用到场景中处理具体的细节逻辑。好在这个小程序没有什么特别复杂的东西。 第 1 坑：去你的 rpx 微信的 rpx 初看起来挺聪明的，把所有的屏幕都映射到 750rpx 的宽度上，帮开发者省去了适应不同屏幕尺寸的麻烦。 但是！rpx 的坑就来了： 接口返回的数值基本都是标准的 px，我要设定 rpx 的话还要 x2。有时候不得不混用 px 和 rpx，简直灾难。（这倒也算不上啥大问题）机型表现不同。嗯，道理我懂，可有时候四舍五入出来露了 1px 的缝出来就会有明显的问题。还有设置字体大小的时候，大屏手机上，自定义导航栏的字体设置成 34rpx 就是比系统级的导航栏 17px 肉眼可见的大。为了方便，让手机屏幕等比放到pad的屏幕上，文字按钮都那么老大个儿，丑不说，让屏幕展示效率奇低，不是啥好主意。不用 rpx 那做适配不就麻烦了吗？其实还好，从我自己这个小程序的需求出发，我的方案是：根据页面需要的最小高度和当前屏幕比例来定一个最大宽度（类似游戏地图的适配逻辑）。对于一般的功能型产品来说，这样相对于用rpx，不仅阅读体验提升了，屏幕展示内容的效率也能有所提升，甚至如果要专门为宽屏（pad）适配新的布局也比较灵活。 第 2 坑：canvas 在小程序里用 canvas，我遇到了两个大坑： 第 2.1 坑，也是最莫名其妙的坑，就是自定义组件盖不住 canvas 的问题，无论自定义组件的 z-index 多高都盖不住 canvas。微信的官方解释就是“原生组件层级最高”，一句话，bug 就变 feature 了？解决方案也只能是：当需要盖住 canvas 的时候，隐藏这个 canvas，然后临时用 canvasToTempFilePath 生成一张假图顶替一下。真挺蠢的。 第 2.2 坑，是锯齿的问题。使用 canvasToTempFilePath 导出图片，会产生锯齿。因为在我的程序逻辑中涉及到至少 3 次将 canvas 导出图片然后重绘到 canvas 上，所以图片质量经过三次下降之后就变像素风了。最终找到的解决方案，竟然是要在绘制的时候给 canvas 的宽高设大一些（大家建议是 2 倍），导出的时候再导出成需要的尺寸。比如需要 1200px 宽的图片，要给 canvas 设置成 2400px 宽，然后导出的时候再导成 1200px。然后微信又有 canvas 尺寸不能超过 4096 的限制，所以当图片高度大于 2048px 的时候，我只能再把放大倍数调低一丢丢… 第 3 坑：云托管（其实，还好） 云托管，一键完成配置，我不用再另外自己搭个后台环境了。而且资源也是弹性的，对新手比较友好。 但作为一个挺业余挺业余挺业余的开发者，我这个“新手”可能过于新了： dockerfile 是啥？Docker 又是啥？我到现在也没搞懂。Sequelize？完全没用过啊，不过看起来挺简单。可是sequelize.org这文档写的…为什么一直报错？SQL的语句里为什么不能用Rank()？什么？MySQL 5.7 是什么鬼？你到底会收我多少钱啊，费用中心里啥也没有，资源用量说了也跟没说一样，我不会用破产吧，我好慌啊……总之，我觉得程序员的世界太不容易了，天天要面对这么多对用户（程序员）不友好的产品（框架、文档、服务…… ）。 最后，先跑起来再说 不过世界就是这么个草台班子，到处都是不完美，到处都是对用户不友好，可是又不得不用的产品。所以当自己是设计的时候，就尽量帮着用户对产品吹毛求疵，力求完美。但哪有完美的东西，有几个 1px 的坑不碍事，先跑起来再说。