好久不见，大家还好不好

小程序小游戏获客越来越难了，但是通过群分享是最简单有效的方式，我建了个互助群，大家有需要的都可以进来

common main.wxss 文件会自动加上这些代码 本身这个文件已经无法访问 会导致加载速度变慢不说 还报错（仅导出正式版有 ）。

@ - webkit - keyframes shadow - preload {
0 % {
background - image: url(https: //cdn1.dcloud.net.cn/517a6b774d3055775253556c643367344f5455354d3245324f5455334d444d31597a6b77/img/shadow-grey.png)}100%{background-image:url(https://cdn1.dcloud.net.cn/517a6b774d3055775253556c643367344f5455354d3245324f5455334d444d31597a6b77/img/shadow-grey.png)}}@keyframes shadow-preload{0%{background-image:url(https://cdn1.dcloud.net.cn/517a6b774d3055775253556c643367344f5455354d3245324f5455334d444d31597a6b77/img/shadow-grey.png)}100%{background-image:url(https://cdn1.dcloud.net.cn/517a6b774d3055775253556c643367344f5455354d3245324f5455334d444d31597a6b77/img/shadow-grey.png)}}

解决办法：打开你的安装目录
D:\ProgramFiles\HBuilderX\plugins\uniapp-cli\node_modules\@dcloudio\uni-cli-shared\lib\platform.js
把第24行改为

return `${tagName}::after{position:fixed;content:'';left:-1000px;top:-1000px;-webkit-animation:shadow-preload .1s;-webkit-animation-delay:3s;animation:shadow-preload .1s;animation-delay:3s}`

保存后 重新导出程序就没有这个了

'''# App 发布就完事了？开发者常见的 iOS 安全误区与纠偏实践

App 发布之后，是不是就可以专注下一个版本了？不少开发者心里是这么想的。尤其是中小团队、独立开发者，发布节奏快、测试资源有限，对 App 安全的关注往往止步于“签名没报错、能装能用”。

但现实比你想的复杂。本文就来聊聊我在 iOS App 发布过程中踩过的几个“安全误区”，也结合工具使用经验（如 Ipa Guard）聊聊我们是如何逐步搭建起自己的 App 安全防线。

一、误区一：源码加密就够了？

很多人觉得“我们已经做了混淆了”，但混淆往往只是改了几个类名、方法名。使用 Swift 编写的项目，symbol 信息仍然极容易被工具提取出来。例如：

swift  

复制编辑  
func fetchUserTokenFromServer() -> String

即使函数名被换成 a1()，内部逻辑仍然一目了然。更别说资源文件、js、json、html等基本都没动，暴露严重。

纠偏建议：不仅要混淆源码，还要混淆输出的 IPA。

我们尝试过使用 Ipa Guard 来处理编译后 IPA 的内容，它可以把类名、方法名重命名为乱码，资源文件名随机重排，甚至修改 MD5、UDID 值，还能在本地直接重签名测试，做到“即改即测”，不依赖源码。

二、误区二：App Store 审核就等于安全？

Apple 的审核确实会抓一些敏感行为，但不等于它会为你的 App 做安全审计。很多开发者误以为“能上架就很安全”，忽略了上线后的二次传播风险。

比如被中间人抓包、工具注入调试、资源提取改 UI，这些都不在 Apple 的审核范畴内。

纠偏建议：上线前做一次完整的安全性测试。

• 用 Hopper 看看你的 IPA 暴露了哪些类名/符号；
• 抓包试试看是否有未加密接口；
• 尝试模拟器运行/越狱环境运行是否触发保护机制；
• 用工具像 Ipa Guard 处理后，再反编译一遍看效果。

三、误区三：项目没那么值钱，不用搞这么复杂？

不少开发者觉得“我这个 App 没人抄”，“又不是支付类工具”，于是对安全几乎不设防。直到某天上线的 App 被换了广告 SDK、挂了推广链接、甚至植入木马发出去。

纠偏建议：安全防护不是为了防御全部攻击，而是延长你被破解的时间成本。

就像加锁一样，没人说锁能防贼，但能防住那些“想试试的”。App 混淆处理也一样 —— 不是为绝对安全，而是为安全边际。

四、混合工具链实践：我们怎么做的？

给大家分享一下我们目前的流程，适合中小开发者团队：

复制编辑源代码结构规范 + 轻量混淆脚本（Swift Shield）   
→ Xcode 自动构建 + strip 工具符号剥离   
→ 编译完成后使用 Ipa Guard 执行 IPA 层混淆   
→ 加壳（如必要）+ 本地重签名测试

为什么使用 Ipa Guard？因为它无需修改原代码，也不会破坏项目结构。而且混淆后的效果明显，在 Hopper 中类名都变成了无意义的字符串，看不出业务线索。

五、除了 Ipa Guard，我们还测试了这些工具：

组合使用这些工具，有助于提升“攻击者的门槛”。

六、总结：App 安全是一场“减速战”

安全无法阻止黑客，但可以拖住他们的脚步。开发者的目标不是绝对保护，而是尽可能加高破解成本，赢得修复时间。

如果你目前还没开始做 IPA 层的保护，不妨试试 Ipa Guard 或类似工具，加上一层防线，也许会在关键时刻救你一命。'''

'''我们是一个小团队，主力成员做 Web 和 Android 开发，谁也没 Mac，谁也没碰过 Xcode。但偏偏有客户指名要上架 App Store。

一开始我们真的很慌，甚至考虑外包这部分流程，直到我无意间刷到了 Appuploader（简称AU）这个工具。

以下是我们“无 Mac 上架 iOS”的完整实践流程，适合和我们一样资源有限、但又不想依赖第三方服务的技术团队参考。

第一关：证书与描述文件，卡得最狠

Apple 的开发者中心并不为“非 Mac”环境设计。我们最初试着用 openssl 自建证书，再去 Apple 后台绑定，问题不断。

后来切换到 Appuploader，只输入 Apple ID 和密码，就能：

• 创建开发和发布证书（支持 p12 导出）
• 自动生成并下载描述文件
• 明确标识哪些设备、哪些 Bundle ID 匹配

整个流程完全 GUI 操作，对非 iOS 出身的成员非常友好。

此外，AU 可以保存历史生成记录，我们发现它比钥匙串要好管理得多。对于不同项目使用不同证书的团队来说，尤其省事。

第二关：IPA 打包上传，看似简单其实坑多

我们是用 Flutter 构建 iOS 包的，在构建完 IPA 后试过手动上传到 App Store Connect，但网站经常抽风，进度提示很不友好。

后来尝试 AU 的上传功能：

• 拖进 IPA 文件，点击上传
• 能看到实时上传进度和日志输出
• 上传后自动触发 App Store Connect 中的“等待提交审核”状态

体验感几乎是“所见即所得”，对比之下，Transporter 反而显得笨重。

而且 AU 上传不依赖系统环境，我们还成功在虚拟机里模拟上传流程，说明其底层实现很稳。

第三关：多语言截图上传与信息填充

我们的应用计划面向多个地区发布，App Store Connect 的表单输入太原始了。

AU 支持：

• 批量导入截图和元信息（CSV 模板）
• 覆盖标题、副标题、描述、关键词等字段
• 多语言自动匹配

我们用 Google 表格协作编辑表单，导出为 CSV，一次导入，非常流畅。

这一部分特别适合版本更新频繁的产品。后来几次迭代版本上线，我们都是直接复制表格、改几个字段、重新导入上传，节省大量操作时间。

第四关：测试设备安装

上线前需要内部测试，尤其是二维码扫码安装，能省下不少部署时间。

AU 提供了一个类似 TestFlight 的功能，可以生成安装链接或二维码：

• 可配置测试账号
• 通过 USB 或局域网快速部署
• iPhone 扫码即可安装

虽然功能比不上 TestFlight 的统计与分发能力，但作为内部测试用，效率足够。

我们后续甚至打算自建一个私有 App 分发系统，但目前来看 AU 已足够覆盖日常需求。

关键细节：协作流程搭建

多人协作中，AU 的优势是：

• 证书和描述文件导出后可共享
• 上传操作无环境依赖，不挑电脑
• 配置模板一次设置，多人共享使用

我们还建立了一个 Notion 项目页，记录各个上传版本、审核状态、截图变动内容等，保证上架流程“有迹可循”。

而这些整理好的记录，也成为了我们团队 onboarding 新人时的重要文档资产。

审核流程提醒：

虽然上传成功了，但审核仍然是个不定时炸弹。

一些建议：

• 功能截图不要纯 UI，要展示交互流程
• 涉及用户数据采集时要写明隐私政策
• 提供 App 使用演示视频可以减少被拒的概率
• 英文说明必须完整、清楚

AU 虽然不能代替你写文案，但它的稳定上传能力能让你专注准备这些材料。

总结：小团队照样能搞定 iOS 上架

Appuploader不是唯一解法，但它让我们从“啥都不会”快速过渡到“稳定出包”。

它的优势在于：

• 全平台兼容（Win/Linux/Mac）
• 功能覆盖完整上架流程
• 易于上手，适合非 Apple 系生态开发者

这次上架经历让我们意识到，技术门槛并不是问题，问题在于有没有合适的工具与流程。

希望这篇实践记录对也在为 iOS 上架苦恼的小伙伴有所帮助。欢迎在评论区讨论你们的流程、工具推荐或上架踩坑经验！'''

'''## 从抓不到包到解决线上Bug：一个程序员的网络调试心路（含抓包大师 Sniffmaster实战）

刚入行那会儿，我以为开发的重点就是“代码写得对”。直到某次线上崩了，我被产品和测试团团围住，却只能尴尬地说：“我这边没问题啊。”

从那天起，我开始补课——不是去学算法，而是琢磨网络调试到底该怎么做，尤其是 HTTPS 抓包这件事。

这篇文章不是教程，而是记录我作为一名普通开发者，从不会抓包到能靠工具独立定位线上 Bug 的过程。希望能帮到也在这条路上“迷茫”的你。

一开始：抓包等于“设置代理 + 安装证书”

在我刚接触网络调试时，身边人都说：“用 Charles 啊，很方便。”

我照做了：设置代理、导证书、信任证书、启动 App……

结果 App 一启动就崩。又试了 mitmproxy，命令行跑得飞快，但 HTTPS 抓不到，双向验证直接拦住。

那时我才意识到：“抓包”这件事，对于一些安全要求高的 App，并不是想抓就能抓的。

初次尝试抓包大师 Sniffmaster：一个“插上就有数据”的瞬间

某次临时接了个金融App的故障排查任务，后台接口频繁 timeout，但前端日志什么都没有。常规工具全都抓不到 HTTPS 数据。

一个同事扔我一个安装包，说：“你可以试试这个，叫抓包大师 Sniffmaster。”

我没报太大希望，但当我插上 iPhone，打开工具后，界面上瞬间刷出 HTTPS 请求数据的那一刻，我整个人“电了一下”。

这玩意儿根本不需要代理、不需要越狱、不需要动系统设置，只要设备一插，立刻开始抓HTTPS。而且还能：

• 过滤非目标 App 的请求，干净高效；
• 支持 JS 拦截器，能即时修改请求参数测试；
• 导出 Wireshark 格式，可交给安全同事进一步分析。

那次我们找到了一个因 CDN 节点配置异常导致的重定向问题，用时不到20分钟。

实际使用场景：不止一次救急

场景1：测试环境正常，线上环境一直 403

抓包后发现，线上多了一个请求头，造成了认证失败。

场景2：某些用户说数据“加载不出来”，复现不了

指定 App 抓包后，发现是接口请求被重定向到旧域名，导致返回的 JSON 数据结构不同，前端直接解析失败。

场景3：与第三方 SDK 接口对接失败

第三方 SDK 启用了 SSL Pinning，用 Charles 无法拦截，Sniffmaster 直接抓到明文数据，定位参数格式错误。

我的网络调试工具箱：现在长这样

每个工具我都装着，根据问题类型灵活切换。

抓包之外：要提升的是“排查意识”

工具好不好是一回事，什么时候该抓包，什么时候不该，全看经验。

• 请求发不出去 ≠ 网络问题，可能是Header出错；
• 没有响应 ≠ 服务端挂了，可能是重定向被拦截；
• 正常返回也 ≠ 正确结果，有时你只是看错了字段名。

我在抓包这条路上走了不少弯路，现在回头看，很多时候“不是不会写代码”，而是“不会看数据”。

结语：工具不会替你解决问题，但它能带你找到真相

现在，我的 Mac Dock 栏里，Charles、Wireshark 和 Sniffmaster 是并排放着的。

每当项目进入“上线倒计时”，我就知道，是时候用它们再做一轮抓包体检——就像是给产品做一次“网络核磁共振”。

如果你也在为 HTTPS 抓包发愁，不妨多试几种方式，哪怕只是抱着试一试的态度。毕竟，解决一个线上 bug，永远比写一行完美代码更有成就感。'''

'''作为一名移动开发者，我常说：“真正的 Bug 不是功能崩了，而是用户说卡了。”尤其是性能类问题，在日志看不出，测试复现难的情况下，经常成了我们开发中最难啃的一类。

今天这篇文章，分享我在几个实际项目中遇到的典型性能难题，以及当时是如何借助多种工具定位和解决的。期间我会提到我常用的几款工具，包括 Instruments、PerfDog、KeyMob（克魔）等，都是我实打实用过的，分享一些搭配使用的小经验。

场景一：UI不卡，但“感觉卡”——滑动流畅度诡异下降

某次 App 列表滑动流畅度不佳，但测试跑下来 FPS 始终是满帧，Instruments 也没发现明显掉帧点。

后续我在设备上并行跑了两套工具：一边用 Instruments 抓具体调用栈，另一边用 KeyMob 查看实时 CPU 和内存图。对比后发现滑动期间CPU 突发波动与一次主线程任务同步有关。

结合 KeyMob 的日志过滤功能，我找到了几段图片解码逻辑偶发同步到主线程的路径。这种问题当然用系统工具也能查，但在实际开发节奏下，KeyMob 的并行视图和日志关联，在快速回溯路径时帮了大忙。

场景二：测试没事，上线崩溃——内存持续增长导致 OOM

在某个视频类项目中，我们上线后收到不少 OOM 报告。但 Crashlytics 给出的堆栈指向并不明确，且复现困难。

我和测试同事尝试了多设备连续使用，工具选择上，我们用了 PerfDog 的内存趋势图，也尝试了 KeyMob 的“App级内存监控”。

KeyMob 的优势在于能直接定位到哪个 App 正在“悄悄吃内存”，并且支持低频定时记录。我们通过这些记录回溯到一个播放器模块未及时释放缓存的问题。整体来看，这类工具配合使用效果更佳，Instruments 做细查，KeyMob 和 PerfDog 负责前期发现与趋势捕捉。

场景三：崩溃日志太乱，符号化太麻烦

多版本测试时，Xcode 的崩溃日志查看功能在切换 dSYM 文件上略显繁琐，尤其我们同时跑着不同分支版本。

我自己在设备端用了 KeyMob 的“崩溃日志管理”模块，它支持设备日志提取后自动符号化，并可按时间、App 分类存档。这在集中排查某一时段特定设备问题时很方便。

当然，并非说系统日志不好，只是在一些协作场景下，这种图形化的管理方式减少了测试同事提取日志的门槛。

补充几个我也常用的工具推荐

• Xcode Instruments：深度分析首选，功能最强，适合专项调优。
• Bugly/Crashlytics：线上崩溃追踪必备，便于汇总报告。
• Reveal：查看 UI 层级、布局问题非常方便。
• PerfDog：可视化详细，适合连续测试，尤其是电量监控。

不同工具各有所长，选择主要看你处在哪个阶段、需要多大粒度的洞察。

小结

性能调优是长期战，不可能靠某一个工具一劳永逸。我的建议是：构建自己的组合式工具链，根据问题性质灵活选用。

以我目前的项目为例，我通常这样搭配：

• 发现问题：KeyMob（查看趋势、设备日志）、PerfDog（连续监控）
• 深入分析：Instruments（调用栈分析、内存快照）
• 线上验证：Bugly、Crashlytics
• 沙盒数据导出：iMazing + KeyMob
• 日志管理协作：KeyMob + 自建日志工具链

KeyMob 对我来说，是那个“随时可拉起”的轻量伴侣，不替代系统工具，但能大幅提高效率与协作便利。

希望这些实际经验能给你带来一些参考。后续如果你对某一类问题处理想听得更细，也欢迎留言，我们继续技术交流。'''

如代码中所示，有绿色、红色2个 movable-view 组件，都设置了 :out-of-bounds="true"，但移动时：
1、绿色的只能在 movable-area 的大小区域内移动，无法移动到以外的地方；
2、红色的只能在 movable-area 的大小区域内 右以外 下以外移动，而无法移动到左以外、上以外的区域；
麻烦帮忙看看这是啥原因，按照文档设置了 :out-of-bounds="true"，movable-view 组件可以移动到 movable-area 以外的区域

   <movable-area style="margin: 100px 0px 0px 50px; width: 300px; height: 300px; background: #ddd;" :scale-area="false">  
    <movable-view  
      style="width: 50px; height: 50px; background: green;"  
      direction="all"  
      :inertia="false"  
      :animation="false"  
      :scale="true"  
      :out-of-bounds="true"  
      :scale-min="0.5"  
      :scale-max="3"  
      @change="onChangeMovable"  
    >  
    </movable-view>  
  </movable-area>  
  <movable-area style="margin: 100px 0px 0px 50px; width: 300px; height: 300px; background: #ddd;" :scale-area="false">  
    <movable-view  
      direction="all"  
      :inertia="false"  
      :animation="false"  
      :scale="true"  
      :out-of-bounds="true"  
      :scale-min="0.5"  
      :scale-max="3"  
      @change="onChangeMovable"  
    >  
      <view style="width: 50px; height: 50px; background: #f00;"></view>  

    </movable-view>  
  </movable-area>

'''如何在非 Mac 环境下高效上架 iOS 应用：使用 Appuploader 的跨平台开发者经验分享

正文：
作为一名跨平台开发者，我曾多次陷入一个令人头疼的循环：开发工作在 Windows 或 Linux 上顺利推进，到了要将 iOS 应用提交至 App Store 的阶段，却因没有 Mac 环境而不得不借助朋友的电脑，甚至干脆租用远程 Mac 服务。

我们都知道，iOS 应用的上架流程本身就相当繁琐。从申请开发者账号、创建和下载各种证书，到配置描述文件、打包上传 IPA、上传截图、设置本地化信息，每一个环节都可能卡壳。而当开发环境本身就不在 Mac 上时，整个过程难度倍增。

这里我分享几个自己使用过、或者在社区中开发者推荐较多的工具和方法，供大家参考：

1. 使用 Fastlane 自动化流程

Fastlane 是众所周知的 iOS 自动化利器，它可以自动完成打包、签名、上传 App Store 等步骤。理论上，Fastlane 在 Linux 和 Windows 上也可以运行，但很多功能仍然依赖 Xcode 或 macOS 原生环境，配置起来相当复杂。尤其是上传 IPA 到 App Store 的 deliver 工具，底层仍然依赖 Transporter 或 Xcode 工具链。

2. 利用远程 Mac 服务

服务如 MacStadium 或 AWS EC2 Mac 实例，可以提供远程的 macOS 环境来处理证书、构建、上传等任务。这种方式虽然可行，但成本较高，且依赖网络环境，上传大型 IPA 文件或截图常常出现延迟或失败。

3. 使用 Application Loader 的替代工具

过去我们可以使用 Apple 提供的 Application Loader，但这个工具已经不再维护，官方推荐转用 Transporter。Transporter 虽然也能用，但需要 macOS 支持。

直到后来，我在社区中看到了一个新的工具 —— Appuploader。它真正实现了在 Windows、Linux 甚至无 Xcode 环境中，完成包括：

• 创建 iOS 开发/发布证书（不依赖钥匙串）
• 生成并管理描述文件
• 上传 IPA 至 App Store（不携带 Mac 硬件指纹）
• 快速批量上传截图与本地化文本信息
• 通过 USB 或二维码将应用安装到 iPhone/iPad 进行测试

这些功能真正做到了打破平台限制，尤其适合像我一样使用 Flutter、React Native 或 UniApp 等跨平台框架进行开发的开发者。

> 举个例子：我最近参与的一个教育类 App 项目，开发周期紧张，团队中没有任何人使用 Mac。在最后阶段我们借助 Appuploader不到半天时间就搞定了证书、上传测试版、提交审核，整个过程稳定高效，省去了大量配置和沟通成本。

当然，每个项目和团队情况不一样。有些团队依然选择传统方式，有些用 CI/CD 工具配合 Fastlane 或 GitHub Actions 实现半自动上传。也有开发者更偏向全手动流程，亲自管理证书与描述文件。

但对于不想被平台限制、希望把精力集中在产品和用户体验上的开发者来说，有这样一款工具确实极大提升了效率。

结语：

如果你和我一样，不再愿意为上传 iOS 应用而折腾 Mac 环境，不妨了解并尝试 Appuploader等新一代辅助工具。它们正在悄然改变 iOS 开发的流程，降低技术门槛，让更多开发者把注意力放回代码与创意本身。

欢迎在评论区分享你在非 Mac 环境下上架 iOS App 的经验与踩坑故事，也欢迎推荐你正在使用的工具或流程，我们一起探索更高效的开发之路。'''

'''# 日常开发中的网络调试：我为什么把 Sniffmaster 加进工具箱

作为一名开发者，尤其是涉及客户端与后端交互较多的 iOS/Android 工程师，抓包几乎是日常调试中不可或缺的一环。从最早为了查个 400 错误原因，到后来分析 SDK 的奇怪行为、排查中间件请求顺序甚至性能优化，网络调试工具在我开发效率上的提升越来越明显。

这篇文章是我工作中经常用到的抓包工具盘点，也是一次偏实战的工具经验整理。特别提一下，最近我加了一款叫 Sniffmaster 的新工具，下面会讲讲为什么它能进我的“常用列表”。

Charles：可视化抓包的老朋友

Charles 应该是 Mac 用户的标配网络调试工具了。我最初用它是调接口时分析请求格式，它支持图形化展示请求/响应，自动格式化 JSON，挺适合日常使用。

缺点主要是：

• iOS 抓包需要设置代理，繁琐且容易被 pin 卡住；
• 多线程 App 的抓包容易遗漏请求；
• 免费试用期之后比较贵。

但它稳定、插件也丰富，对调试 HTTP/HTTPS 请求依然是主力工具之一。

Proxyman：更现代的 Charles 替代品

最近有不少开发者在用 Proxyman，它在界面上比 Charles 更现代，功能也覆盖抓包、TLS 解密、App 分流等需求。它还支持 iOS 模拟器的自动配置抓包，方便很多。

不过在处理真实 iOS 设备，特别是涉及双向验证的 HTTPS 请求时，它和 Charles 一样无能为力，需要配合 Frida 或其他手段。

Wireshark：协议级神器，但太“重”

Wireshark 是我在抓 UDP 或调 WebRTC 连接时用的工具，它能细致到每一个数据包的比特位，适合底层调试。也支持导出数据流分析、过滤表达式等强大功能。

但也因为“太专业”，如果你只想看个 HTTP 请求头，它就显得“杀鸡用牛刀”了。而且不是开发者都擅长操作这种级别的工具。

Packet Capture（安卓专用）

对于 Android 用户，Packet Capture 是一款非常方便的免 root 抓包工具。它通过创建本地 VPN 实现中间人代理，从而抓到 App 的请求数据。还能自动安装证书进行 HTTPS 解密。

它的问题是：

• 只能抓 Android；
• App 如果启用了 SSL pinning，也还是抓不到。

mitmproxy：命令行神器，自动化首选

如果你喜欢命令行、或做一些抓包自动化操作，mitmproxy 是个非常强大的选择。支持编写 Python 脚本处理请求，可以嵌入测试流程，特别适合接口测试团队。

我有个后端同事写了一个 mitmproxy 脚本，每次调用登录 API 自动保存 token，减少手动抓包的繁琐，非常实用。

抓包大师（Sniffmaster）：暴力 iOS 抓包真的能用

说说我最近越来越常用的 Sniffmaster。一开始是同事推荐，说“插手机就能抓，不用代理、不用越狱”。我半信半疑，但真试过后体验太惊艳：

• 支持 iOS 真机 HTTPS 抓包，完全免设置；
• 能爆破 HTTPS 双向认证（pinning），Charles、Proxyman 抓不到的它能抓；
• 可选指定 App 抓包，提升分析效率；
• 支持写脚本修改请求/响应内容，灵活度很高。

上个月我调一个支付 SDK 请求，Charles 全程无数据。Sniffmaster 一插手机就出来了，而且还能直接修改响应数据模拟成功回调，测试流程缩短一半时间。

Burp Suite：安全圈的常驻工具

做安全测试或渗透测试的朋友，几乎人手一个 Burp。它的抓包功能配合 Repeater、Intruder、Decoder 等工具，可以完成一整套攻击模拟流程。

我平时不会用它调业务代码，但在做敏感接口漏洞扫描时，它确实比开发向工具更专业。

Frida：中间件注入大杀器

Frida 是个动态插桩框架，经常被用来绕过 SSL pinning。你可以在目标进程中注入代码，改写 verify 函数，达到抓包目的。尤其 Android 和越狱 iOS 上效果不错。

但门槛高、配置难，不适合日常开发使用，更偏安全或高级调试用途。

总结：选工具，就像选兵器

我现在的选择逻辑是这样的：

• 日常调接口 → Charles 或 Proxyman；
• 多平台脚本处理 → mitmproxy；
• 深度协议分析 → Wireshark；
• 真机 HTTPS 抓包、App pin 破解 → Sniffmaster；
• 安全测试 → Burp + Frida；
• 安卓快速测试 → Packet Capture。

Sniffmaster 是我少数能“插手机即用”的工具之一，特别是 iOS 这块以前真是死角。而它的 App 筛选 + JavaScript 拦截功能让我可以模拟各种网络环境，测试容错逻辑，特别方便。

你有没有用过哪些好用的抓包工具？或者有什么 iOS 抓包时的独门技巧？欢迎评论一起交流！'''

uniapp-deepseek：基于uni-app+deepseek-v3+vue3+uni-ui从0-1搭建实战跨平台流式输出AI对话模板。集成 Uniapp 对接 DeepSeek-V3 聊天大模型。支持编译到H5+小程序+App端、本地会话缓存、pc端750px宽度展示。

uni-deepseek支持性

1. 支持编译到H5/小程序端/App端
2. 支持各种代码高亮、上下文多轮对话/本地会话存储
3. 支持代码块横向滚动、行号、代码复制功能(h5/app端)
4. 支持图片渲染宽度100%、图片预览功能(h5/app端)
5. 支持链接跳转功能(h5/app端)
6. 修复小程序端表格边框线及各类标签选择器样式失效

技术栈

• 开发工具：hbuilderx 4.57
• 技术框架：uniapp+vue3+Pinia2+vite5
• 大模型框架：deepseek-v3
• 组件库：uni-ui+uv-ui
• 高亮插件：highlight.js
• markdown解析：ua-markdown
• 本地缓存：pinia-plugin-unistorage
• 支持编译：H5+小程序+APP端

项目结构目录

目前uni-vue3-deepseek项目已经发布到我的原创作品目录。
uniapp+deepseek+vue3跨平台ai对话模板

编译到h5端，pc布局以750px宽度显示。

热文推荐

原创uniapp+vue3+deepseek+uv-ui跨端实战仿deepseek/豆包流式ai聊天对话助手。
Electron35-DeepSeek桌面端AI系统|vue3.5+electron+arco客户端ai模板
vue3-webseek网页版AI问答|Vite6+DeepSeek+Arco流式ai聊天打字效果
Tauri2.0+Vite5聊天室|vue3+tauri2+element-plus仿微信|tauri聊天应用
Electron32-Vue3OS桌面版os系统|vue3+electron+arco客户端OS管理模板
uniapp+vue3聊天室|uni-app+vite4+uv-ui跨端仿微信app聊天语音/朋友圈

新版sdk和unipush文档上 feature.plist 有2处不同的地方

不修改feature.plist 不会报错，但是获取不到CID，按照文档修改之后，会因为PGPushServerAct导致项目运行终止，这时候我们替换一下GTSDK.framework为GTSDK.xcframework。在工程的Frameworks文件下删除之前的，add flie新的即可（这里自行操作）。改完还是会报错

这说明 Swift 运行时依赖还是没有被正确链接。99% 的情况下，是因为你的项目里没有任何 Swift 文件，Xcode 不会自动链接 Swift runtime，所以在根目录添加一个空的 Swift 文件,别急，还会有一个报错：
Build input file cannot be found: 'xxxx/HBuilder-Hello/HBuilder-Bridging-Header.h'. Did you forget to declare this file as an output of a script phase or custom build rule which produces it?

还需要在Hbuilder-hello文件下新建一个HBuilder-Bridging-Header.h文件，到此就大功告成了。
最终就是这样的