R包中内置供Rscript调用的可执行脚本的最佳实践

首先明确R扩展定义的各inst子目录语义，不要随意混用目录：

• inst/demo：仅用于存放功能演示代码，默认配套示例数据、交互提示，设计目标是给用户跑示例、学习包功能用，完全不适合无交互的生产流水线场景。
• inst/scripts：惯例用于存放包开发阶段的临时分析、数据处理草稿，不会作为正式可执行入口对外暴露，不适合放生产调用的脚本。
• inst/exec：是规范明确预留的可执行脚本存放目录，包安装后该目录下的所有文件会原封不动保留在包安装路径的exec子文件夹下，语义清晰——其他协作者一眼就能识别出这里的文件是设计为被外部进程直接调用的入口，比把脚本直接扔inst根目录的可维护性高很多。

适配AWS Lambda+Docker场景的最小实现 #

1. 脚本存放路径 #

把入口脚本放在包内的inst/exec/run_pipeline.R路径下。

2. 脚本内容参考 #

直接适配JSON参数传入（兼容命令行传JSON字符串、Lambda常用的stdin传事件两种模式），不要写冗余逻辑：

#!/usr/bin/env Rscript
# 加载依赖，屏蔽启动信息避免污染Lambda日志
suppressPackageStartupMessages({
  library(mypackage)
  library(jsonlite)
})

# 读取输入参数
cli_args <- commandArgs(trailingOnly = TRUE)
if (length(cli_args) >= 1) {
  # 优先从第一个命令行参数读取JSON
  params <- fromJSON(cli_args[1], simplifyVector = TRUE)
} else {
  # 无命令行参数时从标准输入读取JSON
  stdin_con <- file("stdin")
  on.exit(close(stdin_con))
  raw_json <- paste(readLines(stdin_con, warn = FALSE), collapse = "\n")
  params <- fromJSON(raw_json, simplifyVector = TRUE)
}

# 必要参数校验，缺参直接报错退出
required_args <- c("input_csv_path", "db_target_config") # 替换为你实际需要的参数名
missing_args <- setdiff(required_args, names(params))
if (length(missing_args) > 0) {
  stop(sprintf("Missing mandatory input parameters: %s", paste(missing_args, collapse = ", ")), call. = FALSE)
}

# 调用已经封装好的核心主流程函数
do.call(run_etl_core, params)

3. Dockerfile中的调用方式 #

不需要手动拼接复杂的source逻辑，直接通过system.file定位脚本路径即可，兼容性最好：

# 安装自定义R包的逻辑略
ENTRYPOINT ["Rscript", "-e", "source(system.file('exec/run_pipeline.R', package = 'mypackage'))"]

避坑提示 #

• 脚本内不要使用相对路径读写文件，所有静态依赖文件通过system.file()从包内定位，动态路径全部通过参数传入，避免容器工作目录变化导致的路径错误。
• 不要在入口脚本或核心流程中留任何交互代码（比如readline()、menu()），Lambda的无交互环境会直接卡住超时。
• 不需要额外引入optparse、argparse这类命令行参数解析包，你的场景只需要处理JSON输入，用jsonlite足够，能减少Docker镜像体积、降低冷启动时间。
• 如果后续需要多入口脚本，全部放在inst/exec下即可，不要散落在inst根目录或其他子目录。

内容的提问来源于stack exchange，提问作者henryn