深度解构：从chroot到容器——Mock构建环境的隔离技术演进与问题诊断

深度解构：从chroot到容器——Mock构建环境的隔离技术演进与问题诊断

引言：RPM构建的隔离需求

在Linux发行版开发中，RPM包的构建需要一个干净、可控的环境以确保构建的可重复性和可靠性。Mock作为Fedora社区开发的RPM构建工具，正是为了满足这一需求而生。但当我们深入其底层实现时，会发现它实际上是一系列Linux隔离技术的精妙组合。本文将从一个典型的Mock构建错误出发，带你层层深入，理解从chroot到容器的技术演进，并掌握系统性故障诊断的方法论。

第一部分：技术栈的层次解析

1.1 传统基石：chroot

基本原理：

intchroot(constchar*path);

chroot是最古老的隔离技术，通过修改进程及其子进程的根目录视图，将进程限制在特定目录树下。它的隔离是单维度的——仅文件系统。

Mock中的应用：

# Mock早期实现简化的chroot调用os.chroot('/var/lib/mock/root')os.chdir('/')

chroot的局限性：

  • 无进程、网络、IPC隔离
  • 用户和权限仍然共享
  • 设备节点可访问
  • 安全性极低

1.2 系统化容器：systemd-nspawn

架构演进：

systemd-nspawn = chroot + namespace(UTS, IPC, PID, Network, Mount) + cgroups + capability management + SELinux/AppArmor

核心技术组件：

  1. 命名空间隔离：

    # 查看进程的命名空间ls-la/proc/$$/ns/

  2. 控制组资源管理：

    # systemd-nspawn使用systemd的slice管理cgroupsystemd-cgls-umycontainer.service

  3. 机器注册机制：

    // systemd-machined的DBus接口org.freedesktop.machine1.Manager.RegisterMachine()

1.3 构建编排层：Mock

Mock的架构设计：

Mock架构层： ┌─────────────────────────────────────┐ │ 用户接口层 (CLI/API) │ ├─────────────────────────────────────┤ │ 构建策略层 (RPM构建逻辑) │ ├─────────────────────────────────────┤ │ 环境管理层 (容器/Chroot管理) │ ├─────────────────────────────────────┤ │ 隔离技术层 (nspawn/chroot) │ ├─────────────────────────────────────┤ │ 系统调用层 (内核命名空间、cgroup) │ └─────────────────────────────────────┘

配置映射关系：

# Mock配置文件关键参数config_opts={'use_nspawn':True,# 使用systemd-nspawn'use_bootstrap_container':True,# 嵌套容器'isolation':'nspawn',# 或 'chroot'、'simple''namespace':{'network':True,# 网络命名空间'pid':True,# PID命名空间'ipc':True,# IPC命名空间}}

第二部分：问题深度诊断

2.1 错误链分析

原始错误信息揭示了多层故障：

ERROR: Command failed: # /usr/bin/systemd-nspawn [参数...] /usr/bin/dnf [参数...] Failed to register machine: Connection timed out Parent died too early

故障链推导：

1. Mock调用systemd-nspawn创建容器 2. systemd-nspawn尝试通过DBus向systemd-machined注册 3. DBus连接超时（Connection timed out） 4. 父进程（Mock）无法收到子进程确认 5. 父进程超时退出（Parent died too early）

2.2 根本原因探析

DBus通信故障的深层原因：

# Mock启动容器的代码流程defstart_container():# 1. 准备nspawn参数cmd=['systemd-nspawn','--register=yes',# 尝试注册到machined'--machine='+machine_id,...]# 2. 启动子进程proc=subprocess.Popen(cmd,...)# 3. 等待容器启动完成# 问题：如果systemd-machined未响应，这里会超时

systemd-machined的角色：

# /usr/lib/systemd/system/systemd-machined.service [Service] Type=dbus BusName=org.freedesktop.machine1 ExecStart=/usr/lib/systemd/systemd-machined

可能的故障点：

  1. DBus系统总线不可达：权限问题或服务未启动
  2. systemd-machined服务故障：资源限制或配置错误
  3. SELinux/AppArmor限制：安全策略阻止访问
  4. 用户会话与系统会话隔离：用户级systemd与系统级systemd不兼容

第三部分：解决方案的多维度思考

3.1 应急方案：回退到chroot

技术折衷分析：

# Mock的回退机制defget_container_manager():ifconfig_opts.get('use_nspawn')andcan_use_nspawn():returnNspawnManager()else:returnChrootManager()# 回退到chrootdefcan_use_nspawn():# 检查条件：# 1. systemd版本 >= 226# 2. systemd-machined服务活跃# 3. 用户有足够权限# 4. 内核支持required namespacespass

安全影响评估：

  • 隔离性降低：构建过程可能影响主机
  • 依赖污染风险：构建环境可能不纯净
  • 权限提升：构建脚本可能有更高权限

3.2 根本解决：systemd-nspawn环境的诊断与修复

系统化诊断流程：

#!/bin/bash# diagnose-nspawn.sh - systemd-nspawn环境完整诊断脚本echo"=== systemd-nspawn 环境诊断报告 ==="echo"诊断时间:$(date)"echo"系统信息:$(uname-a)"echo"====================================="echo-e"\n[1/6] 检查systemd-machined服务状态"systemctl status systemd-machined --no-pager-l# 正常标准：服务应显示为"active (running)"# 异常情况及修复：# - inactive (dead) → sudo systemctl start systemd-machined# - failed → 查看journalctl -u systemd-machined --no-pager -n 20# - masked → sudo systemctl unmask systemd-machinedecho-e"\n[2/6] 检查DBus系统总线连接"busctl--systemlist2>/dev/null|grep-imachine# 正常标准：应能看到org.freedesktop.machine1# 异常情况及修复：# - 无输出 → sudo systemctl restart dbus# - 权限错误 → 检查用户是否在dbus组，或使用sudoecho-e"\n[3/6] 测试DBus方法调用"dbus-send--system--dest=org.freedesktop.DBus\--type=method_call --print-reply\/org/freedesktop/DBus org.freedesktop.DBus.ListNames2>&1|head-20# 正常标准：应返回成功，列出所有bus名# 异常情况及修复：# - Connection timed out → 检查防火墙/网络策略# - Access denied → 检查polkit策略echo-e"\n[4/6] 检查用户会话状态"loginctl show-user$(id-u)|grep-E"(State|Linger|RuntimePath)"# 正常标准：State=active, Linger=no（对于非daemon用户）# 异常情况及修复：# - State=closing → 重新登录或重启用户会话# - 无输出 → 检查loginctl权限echo-e"\n[5/6] 检查内核命名空间支持"kernel_config="/boot/config-$(uname-r)"declare-Arequired_configs=(["CONFIG_NAMESPACES"]="y"["CONFIG_UTS_NS"]="y"["CONFIG_IPC_NS"]="y"["CONFIG_PID_NS"]="y"["CONFIG_NET_NS"]="y"["CONFIG_CGROUPS"]="y")forconfigin"${!required_configs[@]}";dovalue=$(grep"^$config=""$kernel_config"2>/dev/null|cut-d=-f2)if[["$value"=="${required_configs[$config]}"]];thenecho"✓$config=$value"elseecho"✗$config=$value(期望:${required_configs[$config]})"fidone# 异常修复：缺少内核支持需要重新编译内核或使用兼容内核echo-e"\n[6/6] 检查资源限制"ulimit-a|grep-E"(max user processes|open files)"# 正常标准：max user processes > 1024, open files > 1024# 异常修复：# - 编辑/etc/security/limits.conf增加限制# - 检查/etc/systemd/system.conf中的DefaultLimitNOFILE等echo-e"\n====================================="echo"诊断完成。根据上述检查结果进行相应修复。"

分步诊断表：

检查项正常标准异常现象修复方法
systemd-machinedactive (running)inactive/deadsudo systemctl start systemd-machined
DBus连接org.freedesktop.machine1存在连接超时/拒绝sudo systemctl restart dbus
用户会话State=activeState=closing或无重新登录或loginctl enable-linger
内核支持所有命名空间=y有缺失配置使用兼容内核或重新编译
资源限制进程数>1024, 文件数>1024限制过低编辑limits.conf或systemd配置

深度诊断工具：

# 1. 检查systemd-nspawn的seccomp过滤sudogrep-rseccomp /etc/systemd/nspawn/*.conf2>/dev/null# 2. 检查SELinux策略sudoausearch-mavc-tsrecent2>/dev/null|grepsystemd-nspawn# 3. 查看完整的DBus跟踪（需安装dbus-monitor）sudodbus-monitor--system"interface=org.freedesktop.machine1.Manager"# 4. 检查cgroup挂载mount|grep-E"(cgroup|pseudo)"# 5. 验证用户权限sudo-l-U$USER|grep-E"(mock|systemd-nspawn)"

修复后验证：

# 快速验证systemd-nspawn是否正常工作sudosystemd-nspawn--version# 输出应包含systemd版本信息# 运行一个简单测试容器sudosystemd-nspawn-D/tmp/test-root--ephemeral/bin/echo"Test successful"# 应输出"Test successful"# 测试Mock环境mock--cleanmock--initmock--shell"echo 'Mock环境正常'"

3.3 架构优化：容器管理器的选择

Mock支持的容器管理器比较：

管理器隔离级别启动速度资源开销兼容性
systemd-nspawn中高中等中等新systemd
chroot低快低所有系统
podman高慢高需要容器运行时
docker高慢高已弃用

第四部分：举一反三——构建系统的设计哲学

4.1 隔离技术的渐进式演进

技术选择金字塔：

┌─────────────────┐ │ Kubernetes │ ← 编排层 └─────────────────┘ ┌─────────────────┐ │ Docker/Podman │ ← 应用容器 └─────────────────┘ ┌─────────────────┐ │ systemd-nspawn │ ← 系统容器 └─────────────────┘ ┌─────────────────┐ │ chroot │ ← 文件系统隔离 └─────────────────┘ ┌─────────────────┐ │ 命名空间/cgroup│ ← 内核特性 └─────────────────┘

4.2 Mock设计模式的启示

插件化架构的价值：

# Mock的插件系统设计classContainerManager(ABC):@abstractmethoddefstart(self):pass@abstractmethoddefexecute(self,cmd):passclassNspawnManager(ContainerManager):# systemd-nspawn实现classChrootManager(ContainerManager):# 传统chroot实现classPodmanManager(ContainerManager):# Podman实现

配置驱动的环境管理：

# Mock的多环境配置environments={'minimal':MinimalConfig(),'buildroot':BuildRootConfig(),'epel':EPELConfig(),'custom':CustomConfig()}# 根据需求选择环境defget_environment(name,arch,release):# 动态组合配置pass

4.3 故障诊断的方法论

四层诊断模型：

  1. 应用层：Mock命令和配置
  2. 容器管理层：nspawn/chroot调用
  3. 系统服务层：systemd、DBus
  4. 内核层：命名空间、cgroup、安全模块

诊断流程：

开始 │ ↓ 检查Mock配置 │ ↓ ┌─成功─▶继续构建 尝试启动容器─┤ │ └─失败─▶分析日志 ↓ 检查容器管理器状态 │ ↓ 检查系统服务 │ ↓ 检查内核特性 │ └─▶生成解决方案矩阵

第五部分：未来展望

5.1 容器技术的融合趋势

统一容器接口（CRI）的影响：

// Container Runtime Interface简化了容器管理typeRuntimeServiceinterface{CreateContainer(config*ContainerConfig)(string,error)StartContainer(containerIDstring)errorExecInContainer(containerIDstring,cmd[]string)error}

5.2 构建即服务（BaaS）的演进

云原生构建环境：

# 未来的构建配置可能是云原生的apiVersion:build.openshift.io/v1kind:BuildConfigmetadata:name:rpm-builderspec:source:git:uri:https://github.com/example/rpm-specstrategy:mockStrategy:chroot:falseisolation:nspawnconfig:fedora-38-x86_64

5.3 安全隔离的强化

深度防御策略：

# 多层次安全1. 命名空间隔离（基础）2. Seccomp BPF过滤（系统调用）3. 能力位限制（Capabilities）4. SELinux策略（强制访问控制）5. 镜像签名验证（完整性）

结语：从问题到洞见

本文从一个具体的Mock构建错误出发，深入探讨了Linux容器隔离技术的演进路径。我们看到了从简单的chroot到复杂的systemd-nspawn，再到未来可能的云原生构建环境的演进历程。

关键洞见：

  1. 技术选择是权衡的艺术：在隔离性、性能和兼容性之间找到平衡
  2. 故障诊断需要系统性思维：从应用层一直追踪到内核层
  3. 架构设计决定可维护性：Mock的插件化设计使其能够适应技术变革
  4. 理解底层原理是解决问题的关键：知其然更知其所以然

每一次构建失败不仅是问题，更是深入理解系统工作原理的机会。当我们不仅解决了Failed to register machine的错误，还理解了背后的DBus通信、systemd架构和容器隔离原理时，我们就真正做到了"举一反三，别有洞天"。

拓展阅读与资源

官方文档

  1. Mock项目主页与文档：

    • GitHub仓库：https://github.com/rpm-software-management/mock
    • 官方文档：https://rpm-software-management.github.io/mock/

  2. systemd-nspawn官方文档：

    • man手册：https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
    • systemd容器化指南：https://systemd.io/CONTAINER_INTERFACE/

  3. Linux命名空间与cgroup：

    • 内核文档：https://www.kernel.org/doc/Documentation/cgroup-v1/
    • 命名空间API：https://man7.org/linux/man-pages/man7/namespaces.7.html

深度技术文章

  1. 容器技术原理系列：

    • Linux容器技术基础：https://iximiuz.com/en/series/container-learning-path/
    • 深入理解systemd-nspawn：https://blog.erinc.io/posts/deep-dive-into-systemd-nspawn/

  2. Mock内部原理分析：

    • Mock架构解析：https://blog.packagecloud.io/eng/2015/05/11/build-rpm-packages-with-mock/
    • RPM构建最佳实践：https://rpm-packaging-guide.github.io/

相关项目与工具

  1. 容器运行时比较：

    • Podman：https://podman.io/
    • LXC/LXD：https://linuxcontainers.org/
    • runC：https://github.com/opencontainers/runc

  2. RPM生态系统：

    • RPM项目：https://rpm.org/
    • DNF包管理器：https://github.com/rpm-software-management/dnf
    • Koji构建系统：https://docs.pagure.org/koji/

  3. 内核特性相关：

    • Linux内核命名空间：https://lwn.net/Articles/531114/
    • cgroups v2：https://docs.kernel.org/admin-guide/cgroup-v2.html

视频与教程

  1. Linux容器技术入门：

    • Linux Foundation容器课程：https://training.linuxfoundation.org/training/introduction-to-containers/
    • Red Hat容器技术系列：https://developers.redhat.com/topics/containers

  2. RPM构建教程：

    • Fedora RPM打包指南：https://docs.fedoraproject.org/en-US/packaging-guidelines/
    • OpenSUSE构建服务：https://openbuildservice.org/help/

社区与论坛

  1. 讨论与求助：

    • Fedora Mock邮件列表：https://lists.fedoraproject.org/archives/list/mock@lists.fedoraproject.org/
    • Stack Overflow标签：#mock #systemd-nspawn #rpm

  2. 中文技术社区：

    • Linux中国：https://linux.cn/tag/container/
    • 开源中国容器技术：https://www.oschina.net/project/tag/268/container

通过深入理解这些资源，你将能够：

  • 掌握Mock构建系统的全貌
  • 理解Linux容器技术的底层原理
  • 快速诊断和解决构建环境问题
  • 设计自己的隔离构建系统

记住，技术的学习不仅是解决眼前问题，更是构建系统性的知识体系。当你理解了Mock背后的容器技术原理，你就能举一反三，将这些知识应用到更广泛的场景中，如Kubernetes、Docker、系统安全等领域。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/1119313.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

欧盟EN 18031-1无线设备认证

欧盟EN 18031-1无线设备认证

对于计划进军欧盟市场的无线设备制造商来说，EN 18031-1已成为绕不开的合规门槛。自2025年8月1日正式强制执行以来，不少企业因对标准细节理解偏差，遭遇了产品扣留、测试反复等问题：有的误将旧版EN 303645证书当作豁免依据&#xff…
阅读更多...
EN 18031-1通用网络安全认证新规

EN 18031-1通用网络安全认证新规

2025年8月1日，欧盟正式关闭了无线电设备通往其市场的一道关键“安全闸门”——《无线电设备指令》（RED）下的网络安全要求正式强制执行，而EN 18031-1正是这把闸门的核心钥匙。如果您正在为出口欧盟的无线设备（从智能音箱…
阅读更多...
MT-Safety 标签env 和 locale

MT-Safety 标签env 和 locale

一、先给一句话总览 env 和 locale 并不是“函数线程安全不安全”， 而是说： 这些函数依赖一个“全局可变对象”， 只要这个对象在多线程运行期间不被修改，它们就是安全的。 二、背景：glibc 的 MT-Safety 注解体系 glibc 文档把函数分成几类： MT-Safe：多线程下可并发调用…
阅读更多...
除了安全更新，EN 18031-1还有哪些重要的认证要求？

除了安全更新，EN 18031-1还有哪些重要的认证要求？

除安全更新外，EN 18031-1 作为欧盟 RED 指令下的核心网络安全标准，还明确了访问控制与身份验证、安全存储与通信、网络弹性、技术文档与合规声明四大核心要求，这些要求与安全更新共同构成设备进入欧盟市场的基础安全基线，具体内容…
阅读更多...
写给开发者、内容创作者：当你“快做完了”却开始崩，这不是技术问题

写给开发者、内容创作者：当你“快做完了”却开始崩，这不是技术问题

你可能经历过这种时刻：功能都差不多了、测试也跑起来了、上线只差临门一脚——结果你突然开始焦虑、失眠、疯狂想重构、对细节极度挑剔，甚至找借口把发布往后拖。 《最小阻力之路》把这段状态称为“完成期”的典型难关：越接近成果&#xff0c…
阅读更多...
如何确保设备满足EN 18031-1标准中的安全更新要求？

如何确保设备满足EN 18031-1标准中的安全更新要求？

要确保设备满足 EN 18031-1 标准中的安全更新要求，需从技术设计、流程管控、测试验证三个维度构建闭环体系，覆盖更新包的全生命周期安全，具体可落地的步骤如下：明确安全更新的核心技术要求（标准硬性条款）EN…
阅读更多...
通达信专抓超跌副图无未来

通达信专抓超跌副图无未来

{}RSV:(CLOSE-LLV(LOW,20))/(HHV(HIGH,20)-LLV(LOW,20))*100; K:SMA(RSV,3,1),COLORWHITE; D:SMA(K,3,1),COLORYELLOW; 超跌极限买入:IF(CROSS(K,D) AND "CYS.CYS"<-10 AND REF("ASR.ASR",3)<10,50,0); 超跌反弹:IF(CROSS(K,D) AND K<20,80,20),C…
阅读更多...
安达发|石油化工行业自动排产软件：驱动产业升级的核心引擎

安达发|石油化工行业自动排产软件：驱动产业升级的核心引擎

在石油化工行业向绿色低碳转型的关键期&#xff0c;自动排产软件正以"数字大脑"的姿态重构传统生产模式。据中国石油和化学工业联合会数据显示&#xff0c;2025年我国石化行业规模以上企业产值将突破15万亿元&#xff0c;但行业平均设备利用率仅68%&#xff0c;库存周…
阅读更多...
计算机毕设从选题到答辩，全程可指导（真实案例）

计算机毕设从选题到答辩，全程可指导（真实案例）

每年毕业季&#xff0c;都会有大量计算机专业学生在毕业设计阶段感到焦虑&#xff1a;选题不知道怎么选&#xff0c;系统做了一半卡壳&#xff0c;论文不会写&#xff0c;答辩又担心被问懵。实际上&#xff0c;计算机毕业设计并不是“不会做”&#xff0c;而是缺少清晰的流程规…
阅读更多...
Python+Vue的NBA球星管理系统 Pycharm django flask

Python+Vue的NBA球星管理系统 Pycharm django flask

这里写目录标题项目介绍项目展示详细视频演示技术栈文章下方名片联系我即可~解决的思路开发技术介绍性能/安全/负载方面python语言Django框架介绍技术路线关键代码详细视频演示收藏关注不迷路&#xff01;&#xff01;需要的小伙伴可以发链接或者截图给我 项目介绍 随着信息技…
阅读更多...
通达信日周共振

通达信日周共振

{}{日周共振} DIF:EMA(CLOSE,12)-EMA(CLOSE,26); DEA:EMA(DIF,9); 周DIF:("MACD.DIF#WEEK"); 周DEA:("MACD.DEA#WEEK"); M1:(DIFDEA)/2; M2:(周DIF周DEA)/2; MA60:MA(CLOSE,60); 日趋势:(DIFDEA)/2; 周趋势:(周DIF周DEA)/2; XG:周DIF>0 AND 周DEA>0 …
阅读更多...
AI 量化为什么不敢上线？——我的 Fail-Closed 模板实战

AI 量化为什么不敢上线？——我的 Fail-Closed 模板实战

很多人私下问过我一个问题&#xff1a;“AI 都已经能写策略、跑回测、算因子了&#xff0c; 为什么真正能上线跑真金白银的系统&#xff0c;反而很少&#xff1f;”这个问题&#xff0c;其实不在模型能力上&#xff0c; 而在上线这一步&#xff0c;谁敢签字。一、AI 量化“不敢…
阅读更多...
Python+Vue的大学生创新创业调查问卷系统 Pycharm django flask

Python+Vue的大学生创新创业调查问卷系统 Pycharm django flask

这里写目录标题项目介绍项目展示详细视频演示技术栈文章下方名片联系我即可~解决的思路开发技术介绍性能/安全/负载方面python语言Django框架介绍技术路线关键代码详细视频演示收藏关注不迷路&#xff01;&#xff01;需要的小伙伴可以发链接或者截图给我 项目介绍 随着科技的…
阅读更多...
通达信回归斜率线

通达信回归斜率线

{}回归斜率线A:EMA(SLOPE(C,4)*20C,42); 经典RL:(CLOSE-LLV(LOW,9))/(HHV(HIGH,9)-LLV(LOW,9))*100; 经典K:SMA(经典RL,3,1); 经典D:SMA(经典K,3,1); 经典J:3*经典K-2*经典D; MAHL1:100*((EMA((HL)/2,3)-LLV(EMA((HL)/2,5),30)-(EMA(H,20)-EMA(L,20))) /(LLV(EMA((HL)/2,5),30…
阅读更多...
红娘子双线强弱源码分享贴图

红娘子双线强弱源码分享贴图

{} MID: (HIGHLOWCLOSE)/3;红先锋:SUM(MAX(0,HIGH-REF(MID,1)),a)/SUM(MAX(0,REF(MID,1)-LOW),a)*100,colorred;红娘子:REF(MA(CR,b),b/2.51),colorcyan;
阅读更多...
【毕业设计】机器学习基于python的砖头墙裂缝识别

【毕业设计】机器学习基于python的砖头墙裂缝识别

博主介绍&#xff1a;✌️码农一枚 &#xff0c;专注于大学生项目实战开发、讲解和毕业&#x1f6a2;文撰写修改等。全栈领域优质创作者&#xff0c;博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围&#xff1a;&am…
阅读更多...
如何在 ALCOR 强风控逻辑约束下，如何把 V8.2 年化拉到 28%？——一次“先别死，再赚钱”的量化实战复盘

如何在 ALCOR 强风控逻辑约束下，如何把 V8.2 年化拉到 28%？——一次“先别死，再赚钱”的量化实战复盘

先说一句可能让很多量化同学不舒服的话&#xff1a;如果你的系统解释不清“为什么没死”&#xff0c; 那你谈年化&#xff0c;本身就站不住。这篇文章&#xff0c;我不会讲因子、不讲信号、不讲参数&#xff0c;更不会给买卖策略。 我只讲一件事&#xff1a;在 ALCOR 这种“强风…
阅读更多...
springboot疫苗发布和接种预约系统（11650）

springboot疫苗发布和接种预约系统（11650）

有需要的同学&#xff0c;源代码和配套文档领取&#xff0c;加文章最下方的名片哦 一、项目演示 项目演示视频 二、资料介绍 完整源代码&#xff08;前后端源代码SQL脚本&#xff09;配套文档&#xff08;LWPPT开题报告&#xff09;远程调试控屏包运行 三、技术介绍 Java…
阅读更多...
《波段很赚米》指标 通达信 主图/副图 源码 贴图 说明 无未来

《波段很赚米》指标 通达信 主图/副图 源码 贴图 说明 无未来

{}买:IF("KDJ.J"<0,10,0); 条件:CROSS(9.9,买); VAR1:(2*CLOSEHIGHLOW)/4; VAR2:LLV(LOW,5); VAR3:HHV(HIGH,5); VAR4:EMA((VAR1-VAR2)/(VAR3-VAR2)*100,5); MA1:MA(VAR4,2);{} AA:STICKLINE(VAR4>MA1,VAR4,MA1,3,1),COLORRED; BBB:STICKLINE(VAR4>MA1 AND …
阅读更多...
解锁盲盒新玩法✨定制你的专属小程序

解锁盲盒新玩法✨定制你的专属小程序

&#x1f4a1;想要打造独特盲盒小程序&#xff1f; 这些玩法你的项目都有了吗&#x1f447; ✔️福袋惊喜 – 超值组合随机触发 ✔️一番赏经典 – 人气奖池阶梯抽取 ✔️无限赏模式 – 奖池常驻永不下架 ✔️集合赏专题 – 主题系列成套收集 ✔️进阶挑战 – 收集成就解锁隐藏…
阅读更多...
最新文章

Copyright @ 2022~2023